Как реализовать принцип единственной обязанности?

Question

[Анна С.]

Добрый день!
Имеется класс ProductController и в нем метод add, те добавление продукта. Я так понимаю, что в этом методе должно быть только добавление товара в БД, согласно одному из принципов SOLID.
Но у меня получается, что после добавления товара и его характеристик в БД, используя id добавленного товара, еще реализуется ряд дополнительных методов и запросов, нужных для формирования фильтров в магазине.
Подскажите, пожалуйста, как мне это разнести по разным методам или классам, как сформировать абстракцию, а то пока все в лоб идет.

Comments

[Adamos]

Обращение к БД - это обязанность методов модели того объекта, с которым вы работаете. Методы контроллера нужны для того, чтобы правильно обратиться ко всем нужным моделям. Это и есть его единственная обязанность.

[Анна С.]

Ну да, у меня контроллер и дергает модель - для проверки и валидации данных, потом для их сохранения.

[morricone85]

пример кода в студию

Answer 1

[FanatPHP]

Это хороший вопрос.

Начнем с того, что согласно принципу единственной обязанности в контроллере никакого добавления в БД быть не должно.
Контроллер, вообще, это самая ничтожная часть веб-приложения. Его задача - получить данные из НТТР запроса и передать их в модель и потом передать ответ браузеру. Тупо "подай-принеси".
А вот модель уже и должна записывать в базу, проверять валидность данных и совершать все прочие телодвижения.

чтобы сформировать абстракцию, надо знать задачу не на уровне огрызка туманной фразы, "ряд дополнительных методов и запросов, нужных для формирования фильтров в магазине". Что за запросы? При чем здесь фильтры вообще? Как реализован интерфейс с БД - это ОРМ, прямая работа с БД, что-то ещё?

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

То есть контроллер дергает валидатор и смотрит ответ.
Если есть ошибка валидации, то показывает форму обратно
Если ошибок нет - дергает сервис на добавление товара и потом редиректит куда-нибудь

А сервис уже выполняет все те действия, которые необходимы при добавлении товара.

В принципе, валидацию тоже можно в сервис, но тогда надо продумать обратную коммуникацию с контроллером.

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

Comments

[Immortal_pony]

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

В принципе, валидацию тоже можно в хелпер, но тогда надо продумать обратную коммуникацию с контроллером.

А это вообще можно вынести на системный уровень до обращения к контроллеру.

[FanatPHP]

Завтра другой разработчик создать еще один контроллер из которого нуно будет товар.

простите?

[dmitriy]

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

это задача сервиса

[FanatPHP]

dmitriy, мне несложно переименовать

[Виталий Хоменко]

Immortal_pony, думаю для автора вопроса это будет чем-то запредельным. Лучше что-то простое. Проект, скорее всего, у него тоже достаточно простой

[Immortal_pony]

FanatPHP , пальцы не поспели за мыслью, прошу прочения. Поправил на:

Завтра другой разработчик может создать еще один контроллер в котором тоже будет добавляться товар.

Виталий Хоменко, в этом нет ничего запредельного. Автор еще учится и самое время показать ему правильные подходы, а не делать "так быстрее сейчас" (что сулит только технический долго и броадак в коде).

[FanatPHP]

Immortal_pony,

Завтра другой разработчик может создать еще один контроллер в котором тоже будет добавляться товар.

ну и прекрасно, этот контроллер (или не контроллер, а утилита командной строки по импорту товаров из файла) будет дергать тот же самый сервис.

Answer 2

[Северное Сияние]

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

Comments

[Анна С.]

Нет, у меня после добавления товара в БД вызывается метод addInfoToFilter, который к товару имеет весьма опосредованное отношение, используя только id, присвоенный записи.

[Северное Сияние]

Анна С., и что этот фильтр делает?

Answer 3

[developer007]

Контроллер дергает сервис у которого есть методы для работы с товаром.
ProductService->addProduct(...)

если в этот ProductService сделаете добавление/удаление комментариев к продукту то это и есть нарушение принципа единственной ответственности

Comments

[dmitriy]

скорее всего ему нужен сервисный класс на уровне приложения а не домена,
что то вроде app/Services/Catalog
который работает с товарами, фильтрами и тд

Answer 4

[Сергей]

Совет прочитать роберт мартин чистая архитектура
Хотя бы главу о SRP
Обратить внимание "Мартин определяет ответственность как причину изменения и заключает, что классы должны иметь одну и только одну причину для изменений." Обратить внимание когда допускается все оставить в одном классе и когда желательно разделить класс.

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

Answer 5

[Евгений Самсонов]

Как уже выше написали, всю бизнес логику лучше разместить на уровне модели, а контроллер оставить "тонким".

Чтобы не нарушать принцип единственной ответственности, можно использовать паттерн Наблюдатель. Модель после добавления товара будет создавать событие, на которое смогут подписаться другие компоненты приложения. В результате код, ответственный за разные действия, будет находится в разных сервисах системы, и при этом слабо связан между собой
https://refactoring.guru/ru/design-patterns/observer

Comments

[dmitriy]

Как уже выше написали, всю бизнес логику лучше разместить на уровне модели, а контроллер оставить "тонким".

Тоесть я правильно понимаю под принципом единственной ответсвенности вы предлагаете в модели иметь возможность:
- содержать бизнес логику
- использовать работу с источником данных (субд)
- использовать валидацию модели
- использовать реализацию самой модели (сущности)

?

[Евгений Самсонов]

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

[Анна С.]

Евгений Самсонов, я думала, что в модели, которая относится к классу Product, должна содержаться только логика, связанная с БД и непосредственно товаром. А уже валидация данных, фильтры, исключения и пр. - это работа других компонентов.

[dmitriy]

согласен, п.с анемичная модель предметной области