Суть вопроса такова, что я сейчас работаю над сравнительно небольшим проектом, и там все запросы к доктрине лежат непосредственно в контроллерах, что не по солиду. Но там не только выгрузки, там и обновления и удаления есть, поэтому вынести все на одни репозитории, стандартные от доктрины, не выходит.
Подскажите, может есть проверенная структура расположения такого кода, чтобы не хранить его лишь в контроллерах, так как, если покопаться, можно легко найти кучу дублирования и в консольных командах, что не есть хорошо
- простейшие операции с БД делаются через ORM в Entity.
- сложные зпросы, группировка данных из нескольких запросов, квери билдеры - в репозитории
- весь остальной код бизнес-логики, который работает с полученными из БД данными - в хелпере.
При этом надо обязательно помнить, что кроме работы с БД из контроллера надо убрать и всю остальную бизнес-логику. В сервис/хелпер.
Для проверки правильности разделения безнес-логики надо сделать консольную коменду, которая делает то же самое, что и экшен контроллера. Если в команде не дублируется код из экшена (за исключением вызова хелпера) - значит разделение получилось успешно
Обычно, бизенс-логику выносят в отдельный слой. Напишите классы-сервисы, куда и поместите свою бизнес-логику. Где они будут лежать и как называться - это, по сути, ваше дело уже. А сами сервисы потом уже инжектите в контроллеры и вызывайте нужные вам методы.
С бизнес-логикой то понятно, но у меня вопрос не о ней, а о том где и как лучше складировать методы запросы к базе, они же SELECT \ UPDATE \ DELETE запросы к доктрине.
Олег Лысенко, с репозиториями я знаком и сейчас их использую, но они позволяют писать только методы на выборку (find), а я хочу вынести еще и запросы на обновление\удаление. Конечно можно написать репозиторий с методом findAndDestroyById но это уже будет какой-то велосипед с восьмерками на обеих ободах
Вадим Милевский, ну вообще, примерно так и апдейтятся или удаляются отдельные сущности, если вам надо их обрабатывать пачками, работайте напрямую через QueryBuilder внутри репозитория, а не через EntityManager
Средний
