Ответственность Контролера или Сервиса? - PullRequest
0 голосов
/ 02 апреля 2019

У меня есть вопрос об ответственности Контроллера и сервиса за кусок моего кода. У меня есть HTML-форма для сохранения статьи, которая может представить три изображения (миниатюру, резюме и тело) с их текстом. Основной текст может содержать несколько изображений в формате Base64. Я получаю их с помощью действия Post, которое принимает объект DTO для поддержки всех входных данных.

Задачи, которые я хочу сделать:

  1. Получить DTO от клиента
  2. Получение изображений с тела
  3. Проверка сводных и основных текстовых правил
  4. Проверка Правил получения изображений
  5. Проверка миниатюр, сводок и правил изображения тела
  6. Спасите их

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

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

Шаг 2 - самый запутанный шаг для меня. Должен ли я сделать это в контроллере или просто передать все DTO в службу, чтобы отделить вещи сам?

Или о проверке текста, должен ли я проверять, например, итоговую длину текста в контроллере или она должна проверяться на уровне службы?

Кто-нибудь может мне это объяснить?

1 Ответ

1 голос
/ 02 апреля 2019

Возможно дублировать .

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

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

) Извлечение изображений из тела

это похоже на то, что вы спроектировали, чтобы иметь возможность получать нужные данные, но это не то, о чем заботится ваша модель предметной области.Например, если ваша форма позволяет сохранить «Объявление о продаже», состоящее из нескольких изображений и некоторого текста, возможно, это объединение данных в бизнес-слое (услуге) представлено одним или несколькими объектами домена, поэтому тот факт, чтоВы получаете тело в любом формате, больше зависит от технологии или транспорта и должно быть прозрачным для вашего бизнес-уровня.Хорошим примером, который поможет вам найти границы, является возможность повторного использования.Как бы вы использовали свой уровень сервиса, если бы вы использовали его, например, из сервиса WCF?Ваш сервис всегда должен получать и выставлять доменные объекты.Возложить на потребительский компонент ответственность за декодирование / кодирование.

3) Проверка Сводной информации и правил основного текста (и всех других проверок)

представляется проверкой,но я не могу сказать, относится ли эта проверка только к домену.Некоторая проверка также выполняется в самом контроллере, чтобы проверить, действителен ли запрос или нет.Таким образом, если эта проверка выполняется для структуры DTO, прежде чем пытаться преобразовать ее, возможно, это проверка контроллера, если вместо этого эта проверка необходима для определения погоды, или ввод не может быть сохранен, вполне вероятно, что в этом случае это будетсчитаться обязанностью другого.Вы упомянули:

например, длина сводного текста

, если это бизнес-правило, то я бы поместил его в объект проверки, отвечающий за проверку "сводного текста"или давайте назовем его снова" Объявление о продаже ".

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

Еще одно замечание: здесь вы спрашиваете об ответственности контроллера, но обратите внимание наВаш «сервисный« слой », я часто видел код, в котором огромный класс обслуживания инкапсулировал всю бизнес-логику и проверку, что очень плохо, потому что опять идет вразрез с большинством твердых принципов.Посмотрите на запрос команды и шаблон декоратора, я люблю их, потому что они действительно помогают разбить ваш код на более мелкие части с единственной ответственностью.Если вам интересно, посмотрите этот пример проекта на github (ядро .net).Я все еще работаю над документацией, но она должна быть достаточно ясной.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...