Как правильно организовать логику приложения в Laravel?

Question

[Георгий Баручян]

Всем привет!
По немного погружаюсь в мир Ларавеля, и назрел у меня такой вопрос: как организовывать логику приложения?
Немного подробнее:
есть контроллер ArticleController
есть Модель Models\Article
и репозиторий Repositories\ArticleRepository

Помимо этого есть категории статей, для которых отдельная модель, отдельный репозиторий
Берем метод show контроллера, для просмотра конкретной статьи

в нем обращаемся к репозиторию и получаем нашу статью или 404 и передаем во view
хочется добавить немного логики и преобразования данных:
1) преобразовать дату в нужный формат
2) увеличить количество просмотров
3) получить отдельное количество лайков и дизлайков (они хранятся в одной таблице)

Немного пошерстив по просторам интtрнета, пришел к выводу, что нужно делать Service

Если так, то в нем мы делаем инкремент количества просмотров, приводим дату в нужный формат, отделяем лайки от дизлайков.

Вопрос в том, как потом эти данные передавать во view, в виде отдельного массива или модифицировать модель

Наверное, с массивом модифицированных данных - это полный бред, т.к. если это будет не просмотр статьи, а вывод списка, то получится каша.

В общем, хотелось бы услышать/увидеть, как кто делает на реальных проектах

Answer 1

[Alex Wells]

получаем нашу статью или 404 и передаем во view

Статью или exception. Не 404. Кроме контроллера никто в приложении не знает, что ты работаешь с HTTP.

преобразовать дату в нужный формат

Дату преобразовывай в Carbon/DateTime в контроллере - в сервис/репозиторий должен попасть уже обьект в UTC.

увеличить количество просмотров

Увеличивай просмотры сервисом в контроллере.

получить отдельное количество лайков и дизлайков (они хранятся в одной таблице)

Получай лайки и дизлайки скоупом модели, который делает withCount под капотом.

как потом эти данные передавать во view

Во вью в данном случае тебе не нужно отдавать никаких доп. данных кроме самой Article, но если приспичило - передавай отдельными параметрами.

в виде отдельного массива

Никаких магических массивов быть не должно. Все что дальше контроллера (включительно) должно заменять непонятные массивы DTO-шками (погугли, есть готовая реализация от spatie, к примеру), потому что массивы не типизируются, непонятно какие там ключи есть, когда они могут быть, откуда этот массив пришел и так далее - dto решает эти проблемы.

Если сильно приспичит, ты можешь вынести всю вышеуказанную логику из контроллера в отдельный класс - это бывает удобно что-бы что-то по-быстрому зафиксать или симитировать чье-то действие, но это редкие кейсы.

Comments

[Георгий Баручян]

Спасибо за ответ.

[Георгий Баручян]

Alex Wells
Попробую описать, как я понял концепт:

для show: контроллер обращается в сервису, сервис к репозитория, репозиторий к модели.
Сервис из полученных данных создает объект DTO и передает его контроллеру
Во вьюхе общаемся с объектом DTO

для списка:
суть такая же, только сервис создает коллекцию объектов DTO передает их в контроллер, а он во вьюху

[Георгий Баручян]

Alex Wells и ещё немного:

Увеличивай просмотры сервисом в контроллере.

Я так понимаю, что сервис должен хранить состояние модели для этого?
но получается не очень складно:
делаю свойство у сервиса $article;
в контроллере запрашиваю у сервиса запись $serviceArticle->getArticle($slug)
Он мне возвращает объект DTO ArticleData
Далее получается, если я в контроллере вызову метод сервиса по увеличению кол-ва просмотров, он изменит он это сделает для $this->article в сервисе, но объект DTO останется со старым значением

и ещё:
если идти по такому подходу, для списка статей нужен будет свой сервис, например ArticleListService, у которого будет свойством коллекция из репозитория?

Мне кажется, что как-то кривовато получается....

[Alex Wells]

Георгий Баручян, что то ты напридумывал себе сам чего-то и сам же пытаешься это решить.

Я говорил, что в сервис выносить такие вещи не обязательно. А если и выносить, то да, на каждое действие будет по классу, но состояние хранить в них незачем.

он изменит он это сделает для $this->article в сервисе

Нет. Просто передай артикл аргументом.

но объект DTO останется со старым значением

Опять нет. Там же ссылка на тот же обьект, он не копируется.

Мне кажется, что как-то кривовато получается....

Потому что для простых вещей ты придумываешь велосипед) Я считаю что что бы таким заниматься у тебя в первую очередь должна быть хоть какая-то выдуманная проблема, которую как ты считаешь ты пытаешься решить. У тебя такая есть? Банально читая best practices там есть аргументы в пользу тех или инных решений. У тебя такие есть?

Подозреваю что нет.

Вообще тут тебе никто не скажет идеальный рецепт. А даже если и скажут, то ввод таких практик в своем мини-проекте не имеет смысла, ибо обычно такие решения заточены под реальные проекты хотя бы средних размеров с кучей программистов и постоянным развитием.

[Alex Wells]

Георгий Баручян, вместо того, что бы сейчас игратся с сервисами и репозиториями, я бы занялся действительно полезными вещами даже на маленьком проекте - разделил бы монолит на модули, почитал про написание внутренних api, написал бы банальные интеграционные тесты, ввел бы CI, какие-нить статические анализаторы (larastan, psalm), обновился бы до 7.4 (с типизацией и прочим)..

Все это будет в разы полезней и, что главное, понятней, чем сидеть и пытаться решить проблему, которой не существует, без опыта в этом.

[Георгий Баручян]

Alex Wells,
Есть небольшой не коммерческий проект, который я решил попробовать, для себя, реализовать на Laravel.
Я пытаюсь найти минимально не кривые подходы. Пробую простые подходы, пытаюсь немного усложнить. Делаю все, для себя.
Как мне это сейчас все поможет?
буду хорошо знать архитектуру фреймворка? классно, а проект так и будет не дописанным.

[Alex Wells]

Георгий Баручян, к фреймворку это не относится. Делаешь же для себя - так дерзай. Говорю же, эти практики - действительно полезны. На маленьком проекте у программиста без особого опыта не имеет значения где находится код - в сервисе или в контроллере, потому что в любом случае и то и другое будет сделано криво и это не имеет смысла. Говорю на своем опыте.

[vism]

Георгий Баручян, надо знать принципы.
Если вы рассматриваете Репозиторий, вы должны понимать что это и зачем это.
А просто впихнуть - это глупость.

То же с сервисами.

То же с DTO
вы исходите не от проблем и знаний, а от сущестования таких вещей. и пытаетесь их впихнуть.

Дак впихните еще фабрику фабрик с декораторами и еще всё в синглетон обените (бред какой-то), но почему бы не попытаться, эти слова ведь существуют.

Вобщем сперва почитайте что и зачем и какие проблемы помогает решить.
Но в любом случае без опыта архитектуры приложений накосячите и будет хуже чем просто в моделях и котроллерах размазать логику, т.к. кучу бредовых связей сделаете, типо "в контроллере запрашиваю у сервиса запись $serviceArticle->getArticle($slug)"

[Георгий Баручян]

vism, не совсем согласен. Изначально был вопрос, выбора подхода. Основная цель была убрать логику из контроллера. Данный подход меня заинтересовал. Далее пытаюсь вникать в тонкости.

[Alex Wells]

Георгий Баручян, зачем ее оттуда убирать? Назови хотя бы одну проблему, которую ты пытаешься таким образом решить.

Да, все орут о том, что код не должен быть в контроллерах. Да, есть причины что бы он там НЕ был. Да, у сервисов есть причина на существование. Да, у репозиториев есть причина на существование.

Теперь вопрос: ты знаешь эти причины? Знаешь проблемы, которые эти подходы решают? Знаешь, что ты можешь столкнутся с этими проблемами (главное)?

Скорее всего нет. Значит ты не можешь знать, что стоит делать и как. Значит в итоге, как сказал vism, у тебя просто получится каша из того, что вы туда впихнули "абы былО".

И нет, у вас не получится хорошая практика, хороший результат. У вас получится каша.

[Георгий Баручян]

Alex Wells, т.е. вы предлагаете делать грязно, пока не понадобится делать красиво

[Alex Wells]

Георгий Баручян, вот например репозитории:
1) от них нет никакого толку на маленьком проекте
2) от них нет никакого толку если нет нужды менять orm/драйвер базы
3) от них нет толку даже если менять драйвер базы на проектах до средних размеров
4) шанс неправильной реализации - 100%. В опен-сорсе нет ни одной адекватной имлпементации репозиториев и критериев к ним. Вообще.
5) сложность поддержки неправильной реализации

Все это говорю на опыте с проекта с работы. Лучше бы там вообще не было репозиториев, чем были такие, как сейчас.

Просто пользуйтесь Eloquent и скоупами (максимально) - этого будет выше крыши.

[Alex Wells]

Георгий Баручян, я к тому, что нормальная архитектура у тебя с ходу не получится. У тебя получится херня, которая лучше была бы написана в контроллерах - это хотя бы рефакторить потом проще.

Зато есть другие аспекты, которые я называл вверху - они действительно имеют вес и там нет никаких дилем по поводу того, как и где.

[vism]

Alex Wells, О, как приятно на тостере встретить адекватного человека! Это очень большая редкость, жму руку!

Георгий Баручян, Eloquent, а именно Active Record это уже по сути функционал репозитария, просто более удобный

Сервисы надо готовить правильно, надо прямо знать, как делать. Я видел много сервисов в Ларавел, которые сильно запутывали проект и все криво.
Я на проектах, где стараются нанять не дорогих программистов даже против сервисов.
Он вроде пытается скопировать как у меня, с ДТО и всё такое. Но блин передает в ДТО сырой реквест и использует его в сервисе. Притом в ДТО только сам реквест как единственный параметр. Зачем?
Вот вам не понятно, что тут не верно. Потому ненадо пока сервисы вам. Используйте модель для повторяющейся логики, просто првально именуйте методы (чтоб без комментария было понятно) и используте Константы для всех статусов, наборов статичных данных и т.п.
Чтоб не было в коде If (status === 'success') или if (category_id == 2).
Делайте If (status === Order::STATUS__SUCCESS) или if (category_id == Category::ID__BOOK).

и вот еще, самое то для начала
https://github.com/alexeymezenin/laravel-best-practices

Answer 2

[vism]

Да, да 99% хомячков делают Repository даже не понимая зачем, и в качестве источника данных только БД и eloquent...
Да, правильно делать Service для логики. и DTO для передачи сложных данных в Service.

Во view передаете всё что хочется, ведь данные для view готовит контроллер как вы захотите.

В общем, хотелось бы услышать/увидеть, как кто делает на реальных проектах

На реальных проектах гонют коней и 99% логика хрен знает где и как, передается через пень колоду всё :)
Бизнесс не любит платить за красивую архитектуру ибо в раза 3 дольше и в перспективе редко выстреливает.
Да есть места, где она сэкономит времени, но часто это оверхэд.
Но минимум Сервис слой лучше ввести.
Другое дело, что если его ввести не правильно!!! а часто так и бывает, если вы не синьор или архитектор, и потом эти кривые сервисы мешают, а не помогают. Но попытка не пытка, темболее если заказчик готов вам платить раз в 5 больше, чем если бы писали на моделях...

Да, да все плохо.

Comments

[Георгий Баручян]

Спасибо за ответ.

[Andrey Helldar]

Георгий Баручян, также можете заглянуть в чат https://t.me/laravel_web