@Snatch87
Битриксоид по принуждению

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

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

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

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

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

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

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

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

В общем, хотелось бы услышать/увидеть, как кто делает на реальных проектах
  • Вопрос задан
  • 533 просмотра
Пригласить эксперта
Ответы на вопрос 2
Alex_Wells
@Alex_Wells
PHP/TS/Kotlin developer
получаем нашу статью или 404 и передаем во view

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

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

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

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

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

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

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

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

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

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

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

Если сильно приспичит, ты можешь вынести всю вышеуказанную логику из контроллера в отдельный класс - это бывает удобно что-бы что-то по-быстрому зафиксать или симитировать чье-то действие, но это редкие кейсы.
Ответ написан
@vism
Да, да 99% хомячков делают Repository даже не понимая зачем, и в качестве источника данных только БД и eloquent...
Да, правильно делать Service для логики. и DTO для передачи сложных данных в Service.

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

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

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

Да, да все плохо.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы