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

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

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

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

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

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

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

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

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

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

Всю логику выносить куда-то. Логика не должна знать о том, что это HTTP - и.е. никаких обьектов HTTP запросов, никаких HTTP ответов, никаких HTTP ошибок. Если нужен 404 - создается эксепшен под юс кейс (типа UserNotFoundException), а в контроллере ловится и переделывается в NotFoundHttpException. Никак иначе.
Ответ написан
BojackHorseman
@BojackHorseman
...в творческом отпуске...
это логика orm
Ответ написан
Ваш ответ на вопрос

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

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