Уровни обслуживания и репозитории

Question

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

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

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

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

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

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

Спасибо

Answer 1

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

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

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

Answer 2

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

Answer 3

Иэн Купер только что написал сообщение в блоге под названием Толстый Контролер как раз по этому вопросу.