@Lopus

Как правильно разделять код между Контроллером и Сервисом?

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

Вот сейчас размышляю над примером:
api: /api/article/update, входные параметры - поле с json данными, файлы image1 и image2 в ArticleController.
Мой первый вариант: сохранить файлы из контроллера, вызывая StorageService.save(image1), изменить модель Article и сохранить через ArticleService.save(article)
Мой второй вариант: передать весь набор данных в ArticleService.save(article, image1, image2) и уже оттуда вызывать StorageService

Или вообще не так мыслю и лучше по другому сделать?
  • Вопрос задан
  • 64 просмотра
Пригласить эксперта
Ответы на вопрос 2
Привет, основная проблема именно в правилах, нет правил кроме стандартов. Стандарты могут быть приняты в рамках проекта, компании, языка и так далее. Поэтому нужно отталкиваться от предметных моделей, от назначений классов, слоёв. Что есть сервис слой, что есть контроллер, что должен уметь класс, какие входные требует класс итп
Как я понял, вы разделили по слоям, и Фасадом для сервисов может выступить как контроллер, так и сервисы, только нужно определить логику валидации. Можете отдельный слой валидации, маппинга сделать. Я бы не усложнил, и вызывал бы с контроллера, если нет причин вызывать оттуда. Но если логика будет усложняться, только тогда уже принимать дальнейшие решения.
Из ваших примеров первый вариант более очевиден, а во втором при сохранении требуется ещё какие то дополнительные параметры
По мне тут бизнес логика в возможности изменения Article, тогда думаю нужно:
  • В модели Article добавить параметр "image1, image2"
  • В контроллера "маппить" входящие в контроллер данные в сущность
  • К данным моделя или поступающих из вне, всегда будет доступ

Чтобы лучше погрузиться в эту область можно почитать про SOLID, DDD, чистую архитектуру.
Ответ написан
Комментировать
DollyPapper
@DollyPapper
Сервисы уровня домена это то место, где хранится бизнес логика вашего приложения (при анемичной модели, то есть той, которая не имеет в себе бизнес логики), сервисы уровня приложения, это вспомогательная логика для приложения, но не связанная с доменом. Контроллеры же - транспорт. Их задача запрос принять, обработать, вызвать кого нужно, сервисы из уровня домена, сервисы уровня приложения и т.д. и отдать ответ обратно. Логики в них должно быть по минимуму. По логике описанной вами ArticleService не должен ничего сам сохранять, это задача ИМХО StorageService, и ArticleService должен эту работу ему делегировать.
Ответ написан
Комментировать
Ваш ответ на вопрос

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

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