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

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

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

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

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

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

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

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

84 голоса | спросил Erik Funkenbusch 30 ThuEurope/Moscow2010-12-30T22:39:33+03:00Europe/Moscow12bEurope/MoscowThu, 30 Dec 2010 22:39:33 +0300 2010, 22:39:33

3 ответа


0

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

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

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

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

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

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

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

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

ответил Josh 30 ThuEurope/Moscow2010-12-30T23:08:00+03:00Europe/Moscow12bEurope/MoscowThu, 30 Dec 2010 23:08:00 +0300 2010, 23:08:00
0

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

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

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

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

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

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

ответил Bozho 30 ThuEurope/Moscow2010-12-30T23:07:45+03:00Europe/Moscow12bEurope/MoscowThu, 30 Dec 2010 23:07:45 +0300 2010, 23:07:45
0

На мой взгляд,

Модель -

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

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

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

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

Итак, Контроллер запросит службу приложений для модели, и поток будет выглядеть следующим образом,

    Controller->Application Services(using domain services)->Model
ответил paragy 30 ThuEurope/Moscow2010-12-30T23:14:33+03:00Europe/Moscow12bEurope/MoscowThu, 30 Dec 2010 23:14:33 +0300 2010, 23:14:33

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132