Уровни обслуживания и хранилища - PullRequest
45 голосов
/ 28 ноября 2008

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

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

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

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

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

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

Спасибо

Ответы [ 3 ]

25 голосов
/ 28 ноября 2008

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

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

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

6 голосов
/ 02 октября 2012

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

5 голосов
/ 04 декабря 2008

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

...