Laravel курс с нуля, база. 27. Класс Service в Laravel
HTML-код
- Опубликовано: 5 май 2021
- Стань спонсором(бусти аккаунт), доступ к собеседованиям:
boosty.to/laravelcreative
Мои платные курсы:
laravelcreative.ru/course
План развития с нуля до middle+:
laravelcreative.ru/other/plan
Группа вк:
laravelcreative
- Ссылка для донатов, спонсорства, пожертвований
yoomoney.ru/to/410011784671592
www.donationalerts.com/r/lara...
- -
. ---
. .
На самом деле когда въезжаешь во всё, всё становится очень даже простым и логичным. А поначалу вообще нихрена не понятно))
Очередное спасибо за очередной кирпичик мне в знания)
Благодарю, так оно и есть!)
спасибо. Конечно уже взрыв мозга). Но вроде как всё понятно. Конечно сразу всего не запомнишь, но главное понимание , а дальше с опытом всё прийдет. Хочу этот курс пройти, дальшеначать ваш следующей. чтобы уже на практике, на реальном примере всё закрепить. А дальше свой проект сделать, чтобы уже самому пройти с нуля до результата.
Правильно!) Отличный подход!)
Спасибо, за урок! Очень крутая и простая подача материала!
Благодарю!)
Автор, большое спасибо Вам за курс, желаю набрать как можно больше подписчиков ну и достигнуть всех остальных целей которые вас мотивируют создавать контент! Решил после 2,5 лет работы на фронте (Vue js) освоить еще и PHP Laravel. После функционального программирования иногда в шоке от ООП, но надеюсь со временем привыкну. Пока мне страшно представить дебагинг легаси на Ларавель 😀😀😀
Курс несколько месяцев назад просмотрел, но ко многим урокам по несколько раз, периодически возвращаясь и восполняя в памяти пробелы. Также многих авторов смотрю, в т.ч. на английском. И вот сейчас могу сказать, по прошествии времени, что лучше Вашего подхода не видел! С точки зрения методологии и подачи материала очень суперски! А многие авторы страдают одним и тем же - сначала объясняют на примитивных примерах, а затем резко перескакивают на сервисы, экшены и т.д., сыпют терминологией и в итоге - каша.
Благодарю)!
Я слышал такое выражение - "вынести логику в экшены". Как я понимаю, что это и имелось в виду. Первый вопрос, который возникает, а зачем все это. Да код в контроллере становится крайне приятно читать, но на маленьком примере выглядит как работа ради работы. Я так понимаю преимущества данного подхода начнут расти с ростом проекта. А еще если все же использовать ресурсный контроллер, а не однометодный, тогда он не будет разрастаться и будет читабелен. Спасибо за урок )
Спасибо, дружище :) Особенно за то, что рассказываешь такие техники программирования типа реквеста и сервиса. Давай еще пожалуйста такое
Шеф, коментарій для розвитку каналу.
Самая большая проблема в изучении новых ЯП, технологий, фреймворков - структурированность. Чтоб шаг за шагом, чтоб ознакомление с новыми терминами было последовательное и логично сопровождало друг-друга. Ваш курс наверное самый идеальный в этом плане. Все четко и по теме! Приятно осознавать, что автор с большим опытом в этом деле и сразу учит тому, что реально будут требовать в кампаниях. За 10 минут умудряется доходчиво объяснить то, на что другие тратят по 30-40 минут.
Согласен с тем, что информации море и порой начинает кипеть башка: где сервисы, реквесты, миграции, контроллеры, вьюшки, как друг с другом связаны и т.д.) Но с Вашим умением логично все объяснить и показать, это становится в разы понятнее и проще во всем этом разобраться)
Самое главное в подобных курсах, это не научить, а дать конкретное понимание, чтоб при появлении вопросов и проблем на реальных проектах, человек знал с чем конкретно он имеет дело и как правильно задавать вопросы Гуглу и ЧатуГПТ))
Спасибо большое за данный курс, лучший! :D
ИМХО если использовать Service то мне кажется логично только с обычными, а не однометодными контроллерами, потому как в однометодном и так все прекрасно видно, без лишних переходов, а вот если обычные использовать, то тогда без разговоров Сервисы прям в тему! Наверное для себя именно такую связку и оставлю, вполне удобно и красиво)
Полностью соглашусь. Когда условно 2 строки на файл в коде, а всё остальное распихано там-сям - только усложняет понимание кода
@@Cadregich на то он и ООП
@@user-cw2rq8vn6i абстракция внутри абстракции. Знаем-плавали. Нужно уметь вовремя остановиться. Иначе потом приходит человек рефакторить твой код и плачет крокодильими слезами от твоей гениальности, что каждая стро4ка метода разбросана по десяти классам
Да и в целом даже не с однометодными контроллерами в текущих примерах итак всё понятно, код метода умещается на 1 страницу. Скорее получаем проблемы, когда надо бегать по куче файлов и пытаться определить, что там и где. Но тут, как я понимаю, смысл именно в простом примере, как можно использовать уровень сервисов. Хотя, если честно, порой все эти чрезмерные усложнения кода кажутся ненужной дичью.
Есть такая книжка "Чистый код", на которую некоторые сеньоры прям дрочат перед сном. Там как раз про такое расписано, что метод, например, не должен быть больше 10 строк, что вся логика должна быть рассована по углам и каждый отвечает за своё (SOLID).
Все очень круто и на высоком уровне потому что разложено по полкам)))
благодарю за урок!
Спасибо)!
Ты лучший!
комент в карму автору! дякую!
Благодарю)!
Огромное спасибо!
Пожалуйста!)
отличный урок!
Благодарю)!
Ну наконец то создал BaseController, не плохо былобы создать и BaseModel и запихнуть туда $guarded
Благодарю!
интересненько
Спасибо за урок. Я тут реализовал добавление поста с учетом is_published и вот что получилось:
public function __invoke(CreateRequest $request)
{
$data = $request->validated();
$tags = $data['tags'];
unset($data['tags']);
if( array_key_exists('is_published', $data) )
$data['is_published'] = 1;
else
$data['is_published'] = 0;
$post = Post::create($data);
$post->tags()->attach($tags);
if( $data['is_published'] == 1 )
{
return redirect()->route('detailPost', $post->id)->with('successCreatePost', 'Пост успешно добавлен!');
}
return redirect()->route('index')->with('successCreatePost', 'Пост успешно добавлен!');
}
Это работает, но как можно сделать лучше? (в request добавил 'is_published' => '')
Вопрос, зачем делать лучше?) Что тебя смущает?)
Думаю нужно будет за такие классные уроки после зп задонатить:)
Ахах благодарю!)
Спасибо за очередной замечательный урок и понятное объяснение) Подскажите пожалуйста, есть ли вариант делать методы сервисов статическими и вызывать в нужном контроллере нужный метод или это плохая практика?
Да Бога ради:) Если надо, то и статическими) Благодарю!)
Вопросик, не писать же все методы из всех контроллеров в одном сервисе так ведь? Придется создавать много сервисов для каждого контроллера, так вот, это каждый раз нужно создавать отдельный контроллер и связывать его с сервисом?
Request ещё ладно но Service, как по мне дак костыль. ИМХО. Может с опытом придёт понимание. Хотя итак понятно... но выглядит, как изобретение велосипеда)
Где регистрация в AppServiceProvider???
А?
А?
А?
У нас на работе не делали BaseController, конструктор прям в контроллере писали, и потом уже вызывали в нужном методе, лишний контроллер создавать не нужно, да и путаницы нет) нормальный ли это подход такой как был у нас ?)
Объясните, пожалуйста, когда мы создаем класс BaseController, в конструктор там передаем Service $service в качестве аргумента. Но где именно мы положили объект в этот $service? Мы же нигде не создавали экземпляр класса Service и не передавали его в конструктор. Или это происходит как-то автоматически, создаётся экземпляр класса Service и передает его в конструктор BaseController? Если так, то где хотя бы проходит эта логика? Буду очень благодарен за ответ, мне это ломает мою голову)
Кстати, тоже не понял этого, по идее когда вызываем контроллер new StoreController там это аргументом идет, но не понятно где это происходит
гугли Service Container, dependency injection
если грубо - фреймворк сам понимает, что ждет класс в аргументах, создает сервис и передает в конструктор.
Можешь объяснить откуда инстанс сервиса в бейсконтроллер приходит? Мы не делаем нью сервис. Ларавел сам это делает за нас?
Спасибо за урок. Только для однофункциональных контроллеров - это какая-то деоптимизация. Получается класс service набухает по "черному", а в контроллерах всего пара строк - сомнительный выигрышь.
Да, єто понятно. Но автор рассматривает с перспективой разростания приложения, вряд ли такие простьіе делают в реальности )))
в документации ларавеля написано, что однометодный контроллер лучше использовать когда какой-то метод сильно разрастается, а как он может разрастись с использованием сервиса? мне кажется лучше использовать или то, или то, возможно я не прав?
мы в сервисе сделали два метода: store и update
а что мешало сделать их в модели?
чтобы не использовать зарезервированные имена, назвать их postStore и postUpdate и все ...
Привет!
Подскажи плиз, как в академической среде эта технология (подход, паттерн) называется? Немного искал, но пока ничего не нашел.
P.S. Благодарю за труд!
Так и называется:)
А почему вместо кучи контроллеров Post не использовать один контроллер ресурсов? Или я что то пропустил?
Наверно что-то пропустил) Есть разная реализация, тут описан один из)
У меня вот такая вот ошибка вышла, говорит что не хватает аргументов при вызове конструктора в базовом классе который мы создали:
Too few arguments to function App\Http\Controllers\Post\BaseController::__construct(), 0 passed in D:\progs\OpenServer\domains\laravel-vue\app\Http\Controllers\Post\PostController.php on line 14 and exactly 1 expected
Можно ли ипользовать такой код
class StoreController extends Controller
{
public function __invoke(PostRequest $request): RedirectResponse
{
$post = Post::create($request->validated());
$post->tags()->attach($request->tags);
return redirect()->route('post.index')->with('success', __('main.record.created'));
}
}
получается у меня $tags приходит из реквеста без валидации, как это для безопасности?
Это же делегирование получается?
а в чём прикол сервисов, если каждый модуль и так разделён на классы-с-одним-методом?
Какой то странный урок и результат. Код с пометкой "сложно поддерживать" из одного места приложения переместился в другое. В чем тогда пруф, в чем мы выиграли при масштабировании приложения?
Тема сервисного слоя абсолютно не раскрыта.
Главное не понятно каким вообще боком Service класс, точнее его экземпляр должен попасть в конструктор контроллера? Что за скрипт, который будет вызывать такой конструктор с этим параметром?
$container = Container::getInstance();
$instance = $container->make(Service::class);
$instance->store($data);
@@user-cp6kl3ek8g Это откуда? Я понимаю, что это делает само приложение, но все же, можно подробнее?
А что мешает прописывать методы в модели, а не в сервисе? Как в том же yii2
должен соблюдаться принцип единственной ответственности. Модель - работа с бд, сервис - подготовка данных к сохранению.
Если кроме прямого сохранения в бд нет никакой логики то смысла в сервисах нет никакого
@@user-vy9hv8yn4n ну это видимо бзики ларавел
Похоже на шаблон Command. Понапридумывали разных названий, для по сути одних и тех же вещей, крен разберёшься. Ладно, посмотрим.
а не кому не показалось что такой классный и нужный концепт не вошел в ларавел
В каких-то компаниях строго, в каких-то нет) Так что вот)
А почему store и update не реализовать в моделе?
Это такой подход в разработке в общепринятом смысле. На самом деле, в любой компании есть свои стандарты, где-то может скажут реализовать кастомный метод в модели. И так далее:)
@@laravelcreative нет смысла создавать сервис, если там не происхот подготовка данных для модели
камент для продвижения
Благодарю!)
Планируешь перенести видосы в рутуб?) в связи с последними новостями?)))
Что со мной не так?) Мне одному кажется Service как раз таки менее читабельным и большей суетой)
Да, наверное, в простых проектах смысла в нем нет. Тоже считаю, что излишнее усложнение логики только затрудняет понимание. Как уже писали тут сервис используется когда есть предобработка данных перед моделью, наверное, в этом есть логика.
Сервисы у них же есть Провайдеры, Фасады, хелперы...
То другое:)
ха а как жп теперь быть с перегруженностью кода класса серсис
Дело не в перегрузке, а в разделении логики)
@@laravelcreative не знаю вы закрутили все с сервисом со слов перегруженности контроллера - помоему все это масло масляное и воспринимается в разы сложнее - так я вижу что контроллер делает и все в порядке ненадо с мокрой пятой точкой по файлам шнырять и заного втыкаться чо там да как
Тогда не используй эту технологию, это всего лишь вопрос удобства) Никто не обязывает)
А ничего, что класс Controller в папке Controllers, от которого extends все контроллеры в свою очередь extends BaseController, мне кажется, что пересечение имен к хорошему не приведет
Откуда такая боязнь написать несколько строк кода в одном файле? За то нет боязни создать сотни файлов. Скоро будем для каждой буквы кода создавать файл. Ни кого не смущает, что обвязка вокруг реального кода больше самого кода?
это примеры в миниатюре, если вы не слушаете что он говорит это лично ваши проблемы
@@modymd88 Если бы только он. Сейчас так делают почти все. Зайдите в исходники самого Ларавел. Там же комментарии к объету длинне самого кода внутри объекта. Мне не понятно в чём выгода. А вместо ответа комментарий типа вашего. Может вы объсните? Раз я плохо слушал, с удовольстием прочитаю. Если будет конкретика.
SOLID
Бред, создавать разные контроллеры для апдейта и сохранения, это нечто конечно
Для мелких пет-проектов, с 1 разрабом, который всё знает, наверное, да. Один контроллер проще поддерживать. С другой тут просто общий концепт не валить всё в кучу. Были проекты, где куча таких взаимосвязей, не всегда очевидных. Т.е. вроде ты поменял в одном месте как просил клиент, а потом оказывается, что этот код еще в 10 местах используется и там посыпалось всё из-за изменений.
не понимаю зачем вы все время пытаетесь обосновать какие то обстрактные преимущества - не факт что они вообще есть
Эх,да(
Объясните, пожалуйста, когда мы создаем класс BaseController, в конструктор там передаем Service $service в качестве аргумента. Но где именно мы положили объект в этот $service? Мы же нигде не создавали экземпляр класса Service и не передавали его в конструктор. Или это происходит как-то автоматически, создаётся экземпляр класса Service и передает его в конструктор BaseController? Если так, то где хотя бы проходит эта логика? Буду очень благодарен за ответ, мне это ломает мою голову)
Есть такая штука (не знаю точно насчет РНР, но в C# точно), как конструктор по умолчанию. Если ты нигде явно конструктор не прописываешь с четко заданными свойствами ( __construct(); ), то он создается на лету, воздухе, под капотом за кулисами театра при первом его вызове. Что-то как-то так. По крайней мере меня это успокаивает и я сплю спокойно.
dependency injection
@@XanderEVGs Это понятно, что это DI, только вопрос в другом был
@@user-lk9kc9vf9t тогда какой ответ?
Вопрос вроде такой: кто создал экземпляр и передал его нашему классу