Куда размещать бизнес логику приложения laravel?

Приветствую, коллеги.

У меня вопрос более общего характера, с которым я столкнулся в процессе разработки приложения.

Где нужно размещать бизнес логику приложения?
Перечитал разные статьи и все они расходятся во мнениях. Одни пишут что в моделях, следуя принципу "худых" контроллеров, другие пишут, что модели отвечают только за работу с полями БД.

Для примера, в моем проекте (интернет-магазин) присутствует фильтр товаров. Вот он используется (пока что) только в контроллере категорий, работает только с таблицами продуктов и параметров. Я выделил класс фильтра в отдельную директорию именуемую Filters (да, там их несколько разных).

Вопрос:
1. На сколько правильно я сделал (и правильно ли вообще)?
2. Все же, куда помещать такие вот моменты бизнес логики?

Заранее благодарю за ответы!
Всем хорошего и продуктивного дня!
  • Вопрос задан
  • 4781 просмотр
Решения вопроса 1
@NubasLol
Мое мнение, что в модельках должна быть логика только связанная с получением данных с базы. Бизнес логика, пишется в отдельных сервис классах, как у вас, например, класс фильтр.

Иначе модель будет расти до тысяч строк кода, и будет мешаниной методов. Принцип же класса в ооп любого, это узкая специализация над одной задачей. Задача модели получать данные с базы, и туда их записывать.

Контроллер же просто дерижер, который принимает запрос, обрабатывает, дергает нужные методы приложения, и отдает ответ. Сложной логики в нем писать не нужно
Ответ написан
Пригласить эксперта
Ответы на вопрос 2
Alex_Wells
@Alex_Wells
PHP/Kotlin
Изначально затея MVP была в этом:
View должно было быть представлением данных, глупым представлением, которое всего лишь смотрит на изменения полей Model и обновляет вид для юзера
Controller должен был отвечать за ввод и вывод информации пользователю. Никакой бизнес логики - лишь команды и ответы.
Model должен был быть представлением данных. Это не значит, что модели должны быть "толстыми" - это значит, что должны быть другие части приложения, отвечающие за бизнес логику. Не модель. И уж точно не та "модель", наглухо связанная с базой данных.

А теперь мое имхо:
1. Контроллеры принимают запрос, валидируют, достают авторизированного юзера, проверяют пермишены. Вызывают ОДИН метод какого-то класса, форматируют результат и отдают.
2. В моделях только логика БД. Никакой бизнес логики от слова "совсем". Никаких зависимостей. Ничего.

Всю логику выносить куда-то. Логика не должна знать о том, что это HTTP - и.е. никаких обьектов HTTP запросов, никаких HTTP ответов, никаких HTTP ошибок. Если нужен 404 - создается эксепшен под юс кейс (типа UserNotFoundException), а в контроллере ловится и переделывается в NotFoundHttpException. Никак иначе.
Ответ написан
@greenst
По моему мнению, бизнес логика как раз и должна быть размещена в модели. Большая ошибка считать, что модель отвечает за работу с базой данных. Это же не коннектор базы данных.
Вся эта путаница возникает из-за того, что многие моменты предметной области пересекаются со структурой базы данных. Те же самые отношения между моделями конечно, позволяют удобно формировать сложные запросы, но в первую очередь хорошо отражают взаимосвязи внутри предметной области.
Кроме того, многие инструменты, которые дают фреймворки для работы внутри модели (события, доступ к старым данным, сеттеры/геттеры и др.) как минимум упрощают последующее понимание кода, резко ускоряют последующие дополнения и отладку.
Чтобы не запутаться в слишком толстой модели лучше всего каждый перед созданием нового метода задуматься: а нельзя ли его реализовать как квери билдер, геттер/сеттер или еще какой-то документированный метод фреймворка. Ну и конечно, никто не мешает из модели вынести какую-то объемную задачу в какой-нибудь выделенный сервис.
В итоге, из различных контроллеров можно просто запрашивать отдельные свойства модели, присваивать им значения. А вся сложная логика будет сконцентрирована в модели. И не нужно будет каждый раз переворачивать на изнанку весь код, если бизнес-логика немного меняется.
Ответ написан
Комментировать
Ваш ответ на вопрос

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

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