Где «бизнес -логический слой» вписывается в приложение MVC?

Question

Во -первых, прежде чем кто -либо кричит Dupe, мне было трудно подвести итог его в простом названии. Другим заголовком могло быть «Какова разница между доменной моделью и моделью MVC?» или "Что такое модель?"

Концептуально я понимаю модель как данные, используемые представлениями и контроллером. Кроме того, кажется, что существует много разных мнений о том, что составляет модель. Что такое доменная модель по сравнению с моделью приложений, против модели представления, против модели службы и т. Д.

Например, в недавнем вопросе, который я спросил о шаблоне хранилища, мне сказали, что репозиторий является частью модели. Тем не менее, я прочитал другие мнения о том, что модель должна быть отделена от модели настойчивости и слоя бизнес -логики. В конце концов, разве шаблон хранилища не должен отделить метод бетонной стойкости от модели? Другие люди говорят, что существует разница между моделью домена и моделью MVC.

Давайте возьмем простой пример. AccountController, который включен в проект MVC по умолчанию. Я прочитал несколько мнений, которые включал в себя код учетной записи плохой дизайн, нарушает SRP и т. Д. и т. Д. Если бы кто -то хотел разработать «правильную» модель членства для приложения MVC, что это будет?

Как бы вы отделили услуги ASP.NET (поставщик членов, поставщик ролей и т. Д.) от модели? Или вы вообще?

Как я вижу, модель должна быть «чистой», возможно, с логикой проверки ... но должна быть отделена от бизнес -правил (кроме проверки). Например, допустим, у вас есть деловое правило, в котором говорится, что кто -то должен быть отправлен по электронной почте при создании новой учетной записи. Это на самом деле не принадлежит модели, на мой взгляд. Так где же это?

Кто -нибудь хочет пролить свет на этот вопрос?

Answer 1

То, как я это сделал - и я не говорю, что это правильно или неправильно, - это иметь мою точку зрения, а затем модель, которая применяется к моему мнению. Эта модель имеет только то, что имеет отношение к моей точке зрения, включая аннотации данных и правила проверки. В контроллере находится только логика для построения модели. У меня есть сервисный уровень, в котором находится вся деловая логика. Мои контроллеры называют мой сервисный слой. Помимо этого, мой репозиторий слой.

Мои объекты домена размещены отдельно (на самом деле в их собственном проекте). У них есть свои аннотации данных и правила проверки. Мой репозиторий проверяет объекты в моем домене перед сохранением их в базе данных. Поскольку каждый объект в моем домене наследует от базового класса, который имеет встроенную проверку, мой репозиторий является общим и проверяет все (и требует наследства от базового класса).

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

Пример при работе с кредитными картами - мне нужно потребовать CVV при обработке платежа, но я не могу хранить CVV (это штраф в размере 50 000 долларов США). Но я также хочу, чтобы вы имели возможность редактировать свою кредитную карту - смена адреса, имени или дата истечения срока действия. Но вы не собираетесь давать мне номер или CVV при его редактировании, и я, конечно, не собираюсь помещать номер вашей кредитной карты в простом тексту на странице. В моем домене есть эти значения, необходимые для сохранения новой кредитной карты, потому что вы даете их мне, но моя модель редактирования даже не включает номер карты или CVV.

Другое преимущество для многих слоев заключается в том, что, если вы правильно архивируете, вы можете использовать structureMap или другой контейнер IOC и обмениваться кусочками, не влияя на ваше приложение.

По моему мнению, код контроллера должен быть только код, нацеленный на представление. Покажите это, скрыть это и т. Д. Служба должен разместить бизнес -логику для вашего приложения. Мне нравится иметь все это в одном месте, поэтому легко изменить или настроить деловое правило. Уровень репозитория должен быть относительно глупым - лишенным бизнес -логики и только запрашивать ваши данные и возвращать объекты домена. Отделяя модели представления от модели домена, вы получаете гораздо большую гибкость, когда речь идет о пользовательских правилах проверки. Это также означает, что вам не нужно сбрасывать каждую часть данных в свое представление в скрытых полях и толкать их вперед и назад между клиентом и сервером (или восстанавливает их на бэкэнд). Затем в вашей модели просмотра будет размещена только информация, относящаяся к представлению - и ее можно настроить, чтобы иметь логики для просмотра или подсчеты или перечисления, чтобы само по себе не было загромождено сложными логическими операторами, такими как

<% if (!String.IsNullOrEmpty(Model.SomeObject.SomeProperty) && 
    Model.SomeObject.SomeInt == 3 && ...) { %>

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

Answer 2

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

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

Но давайте предположим Доменная архитектура, и наши объекты домена - это то, как они должны быть - иметь как государственную, так и бизнес -логику. И в этой доменной перспективе все станет на свои места:

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

Я думаю, это отвечает на ваши основные вопросы. Вещи становятся сложными, когда мы добавляем несколько слоев, таких как слой репозитория. Часто предполагается, что это должна быть вызвана бизнес -логикой, размещенной в модели (и, следовательно, каждый объект домена имеет ссылку на репозиторий). В моей статье, которую я связал, я утверждаю, что это не совсем лучшая практика. И это на самом деле неплохо иметь сервисный слой. Кстати, дизайн, управляемый доменом, не исключает уровень обслуживания, но он должен быть «тонким», и только координирующие доменные объекты (так что нет никакой бизнес-логики).

Для парадигмы анемичной модели данных, которая широко используется (для хорошего или плохого), модель будет как сервисным уровнем, так и вашими объектами данных.

Answer 3

По моему мнению,

Модель -

Не должен содержать бизнес -логику, она должна быть подключена (сценарий WCF). Он используется для привязки для просмотра, это должно иметь свойства.

Бизнес -логика -

Он должен быть размещен на «уровне доменных услуг», это совсем отдельный слой. Кроме того, добавит еще один слой здесь «Службы приложений».

App Services общается с уровнем доменных услуг для применения бизнес -логики, а затем, наконец, возвращает модель.

Итак, контроллер спросит службу приложений для модели, а поток будет поступать,

    Controller->Application Services(using domain services)->Model

Answer 4

Паттерн MVC и структура ASP.NET не отличаются тем, каким должна быть модель.

Собственные примеры MS включают классы постоянства в модели. Ваш вопрос о том, что членство находится в модели. Это зависит. В вашей модели есть занятия в вашей модели? Есть ли связь между тем, кто входит в систему и какие данные отображаются? Существует ли фильтрация данных части системы разрешений, которая редактируется? Кто в последний раз обновляется или отредактировал объектную часть вашего домена, как в ком -то другом, нужно увидеть это или что -то в этом роде для поддержки бэкэнд?

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

Эти типы вопросов чрезмерно широкие и субъективные, но я отвечаю, чтобы вы и все, кто проголосовал за вас, могут понять это.

Ваши требования/временные рамки/ресурсы все истекают в архитектуре вашей системы. Даже Модель дохода может иметь эффект. Вы также должны рассмотреть вопрос, для которого вы снимаете. DDD сильно отличается от приложений Persistence-AS-Model, и все перерывы между между ними также действительны для определенных приложений. Вы снимаете для тестирования приложения? Все это имеет эффект.