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

Question

[Lenskiy-e]

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

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

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

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

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

Заранее благодарю за ответы!
Всем хорошего и продуктивного дня!

Comments

[Barmunk]

в ларавел модели используются только для работы с базой данных, а всю бизнес-логику перемещают в специальные классы "service layer", которые подключают через dependency injection

https://stackoverflow.com/questions/53437781/servi...

[spaceatmoon]

Barmunk, из примера не очень ясно кто в контроллер вкладывает нужный сервис. Можете пояснить своими словами или статьёй? Я делаю так: Есть Middleware <-> UsersController <-> UsersService <-> UsersModel. Бизнес логика в сервисе, контроллер отвечает за валидацию и ответы, а самая худая это модель при этом чаще всего не превышая 10 строк кода.

Answer 1

[NubasLol]

Мое мнение, что в модельках должна быть логика только связанная с получением данных с базы. Бизнес логика, пишется в отдельных сервис классах, как у вас, например, класс фильтр.

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

Контроллер же просто дерижер, который принимает запрос, обрабатывает, дергает нужные методы приложения, и отдает ответ. Сложной логики в нем писать не нужно

Comments

[JhaoDa]

Про контроллер — правильно, про модель — нет.

[NubasLol]

JhaoDa, Поделись как надо)

[Lenskiy-e]

NubasLol спасибо за ответ!

[NubasLol]

Иван, по определнию, ну не обязательно бд, можешь хоть в файл записывать

[NubasLol]

Иван, С чего бы это было моделью?

https://symfony.com/doc/current/forms.html

[Артур]

NubasLol, есть такая практика тонкие контроллеры толстые модели, но не нужно все сводить в абсолют.
Тут у нас модель это реализация active record и в ней может быть логика, но нужно понимать, что за логику вы туда пишите. Работа с данными? это можно, но не нужно писать логику сохранения файла в модели, для этого есть сервисы. Иными словами в модели можно писать логику, но модель должна отвечать только за свои данные, надеюсь суть понятна.

PS. Модель слияние сущности с репозиторием.

JhaoDa согласны?

[JhaoDa]

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

Модель — это, в общем смысле, функция, т.е. некий механизм, делающий что-то. Когда-то он укладывается в один класс, когда-то нет. Когда-то она является отражением БД, когда-то — API, когда-то — сборной солянки.
Если модель является агрегатом, то она отвечает и за всё, что агрегирует.
Если мы посмотрим на доктрину, то сущности (модели) от репозиториев (и слоя хранения вообще) отделены явным образом.

[Сергей]

NubasLol, Ваше мнение мне близко. В Ларавеле так построены модели, что они скорее содержат "настройки" конкретной таблицы БД, чем бизнес логику. Поэтому логику тоже стараюсь переносить в отдельные классы.

Но бывает, что такой вот вспомогательный класс (возьмем тот же Filter) связан с конкретной таблицей БД и, следовательно, конкретной моделью. Как Вы поступаете в данном случае: оформляете этот отдельный класс как трейт, или наследуете от модели, или вообще их жестко не связываете?

Потому что иногда надо же, например, получить список фильтров согласно какой-нибудь особенной логике, и хочется написать что-то типа Filter::getAvailable(). Но если метод getAvailable() у нас в другом классе, то надо уже другой класс вызывать (понятно, что и в Services\Filter::getAvailable() нет ничего крамольного, но все же).

[NubasLol]

SVZhidkow, фильтр пишу в самой моделе, так как он относится к получению данных.

Делаю скоп, в который передается массив, с данными для фильтрации.

Есть сервис класс фильтр, в котором есть методы, для общих фильтров, например, например по дате, и в моделке просто вызывается метол этого сервиса.

А если нужен метод не общий, то пишется просто в самой модели

Answer 2

[Alex Wells]

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

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

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

Comments

[JohnDaniels]

никаких обьектов HTTP запросов

а как тогда делать добавление в бд из формочки на странице?

[Alex Wells]

JohnDaniels, передавать в класс все данные вручную. $request->all() и подобное тоже не катит.

[Lenskiy-e]

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

Answer 3

[greenst]

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