Сервисные слои и репозитории - программирование
Подтвердить что ты не робот

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

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

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

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

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

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

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

Спасибо

4b9b3361

Ответ 1

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

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

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

Ответ 2

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

Ответ 3

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