Сервисные слои и репозитории

Question

Я использую рамки MVC в течение короткого времени, и мне очень нравится, как проблемы отделяются. У меня есть плохая привычка позволять контроллерам выполнять немного работы. Поэтому я действительно ищу совет.

Когда я впервые начал использовать MVC, я довольно часто делал манипуляции с контроллерами на моделях после выполнения работы с базой данных. Я знал, что это так плохо, что они работают в моделях. Однако я не доволен этим, так как хочу, чтобы мои модели очень учились.

Я проделал немного чтения, и я вижу, что люди держат свои контроллеры и модели навязчивыми, имея сервисный слой, который мне нравится.

Я просто пытаюсь понять, как сервисный уровень и репозиторий должны работать вместе. Вот мои предположения, можете ли вы сообщить мне, если это хороший способ работы?

1. Контроллер может вызвать хранилищу напрямую, если не требуется никаких манипуляций быть сделано на основе данных и в качестве такого слоя сервиса не нужно ввязываться
2. После того, как должно быть сделано для данных любой работы (бизнес-логику), то это должно быть сделано на уровне обслуживания, и контроллер выполнит простой вызов уровня обслуживания по мере необходимости
3. После того, как служба выполнила свою бизнес-логику, она затем будет использовать репозиторий по мере необходимости (если данные необходимы сохраняются).
4. Модели идеально должны быть плоскими, идеально действующими как не более чем DTOs
5. Проверка данных будет выполнена в рамках моделей (с использованием атрибутов проверки MonoRail). Я признателен, что даже никто не любит загрязнять свои модели множеством атрибутов, но это другое обсуждение. Мне нравится преимущество атрибутов проверки MonoRail для автоматической проверки jQuery в пользовательском интерфейсе.

Я пытаюсь превратить весь свой код в принцип единой ответственности, поэтому пытаясь разобраться в моих методах кодирования.

Благодаря

Answer 1

Во-первых, не существует набор правил, который будет работать в любой ситуации. Как вы моделируете свое приложение, многое зависит от типа и сложности проекта. Сказав это, вот несколько идей:

1. Ничего плохого в вызове репозитория с контроллера. Просто убедитесь, что контроллер не содержит бизнес-логики.
2. Служба заботится о (некоторой) бизнес-логике и использует другие службы для этого. Репозиторий - это тип сервиса, нет ничего плохого в вызове его из службы.
3. Модель должна содержать бизнес-логику, на самом деле вы всегда должны попытаться поместить ее в модель в первую очередь. Если вам нужны внешние данные для выполнения этой бизнес-логики (из другой модели или из репозитория), вам необходимо создать службу.
4. Ничего плохого в проверке моделей. Использование атрибутов или нет - это вопрос вкуса (если вам нравится, тогда это хорошо). Переместите проверку вне модели, если она становится слишком сложной (создайте внешний набор правил).

Самое важное, делайте то, что кажется правильным (обычно это правильный ответ).

Answer 2

Ian Cooper только что написал сообщение в блоге под названием The Fat Controller только на эту тему.

Answer 3

This видео дает большое представление о том, как организовать решение asp.net MVC и разрешить разделение проблем и лучшую проверку. Надеюсь, это поможет и другому. Я узнал от него хорошие вещи.