Бизнес логика в MVC

Question

У меня есть 2 вопроса:

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

Q2.Является ли «бизнес-логика» такой же, как «бизнес-правила»?Если нет, то в чем разница?

Было бы здорово, если бы вы могли объяснить небольшой пример.

Answer 1

Поначалу:
Я полагаю, что вы смешиваете шаблон MVC и принципы проектирования, основанные на уровнях n.

Использование подхода MVC не означает, что вы не должны разбивать свое приложение на слои.
Это может помочь, если вы видите MVC больше похожим на расширение уровня представления.

Если вы поместите код непредставления в шаблон MVC, вы очень скоро можете получить сложный дизайн.
Поэтому я бы посоветовал вам поместить свою бизнес-логику в отдельный бизнес-уровень.

Просто взгляните на это: Статья в Википедии о многоуровневой архитектуре

В нем говорится:

Сегодня MVC и аналогичные модели представления-представления (MVP) представляют собой шаблоны проектирования с разделением интересов, которые применяются исключительно к уровню представления более крупной системы.

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

Это связано с тем, что контроллер фактически обрабатывает вызовы к определенному ресурсу, запрашивает данные, делая обращения к бизнес-логике, и связывает данные (модель) с соответствующим представлением.

Грязь сказал вам, что бизнес-правила входят в модель.
Это также верно, но он перепутал модель представления ("M" в MVC) и модель уровня данныхпроектирование приложений на уровне уровня.
Таким образом, допустимо поместить бизнес, связанный с базой данных, правила в модель (уровень данных) вашего приложения.
Но вы не должны размещать их в моделиваш MVC-структурированный уровень представления, так как это относится только к определенному пользовательскому интерфейсу.

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

Позвольте мне визуализировать это для вас:

---

Уровень представления: модель - представление - контроллер

---

бизнес-уровень: логика домена - логика приложения

---

уровень данных: хранилища данных - уровень доступа к данным

---

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

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

В этом-то и дело ... Надеюсь, это поможет ...

[Примечание:] Вы также должны осознавать тот факт, что в настоящее время существует более чем одна "модель" вприложение.Обычно каждый слой приложения имеет свою собственную модель.Модель уровня представления зависит от вида, но часто не зависит от используемых элементов управления.Бизнес-уровень также может иметь модель, называемую «модель домена».Обычно это тот случай, когда вы решаете использовать доменный подход.Эта «модель предметной области» содержит данные, а также бизнес-логику (основную логику вашей программы) и обычно не зависит от уровня представления.Уровень представления обычно вызывает бизнес-уровень на определенном «событии» (нажатие кнопки и т. Д.) Для считывания данных или записи данных на уровень данных.Уровень данных также может иметь свою собственную модель, которая обычно связана с базой данных.Он часто содержит набор классов сущностей, а также объектов доступа к данным (DAO).

Вопрос: как это вписывается в концепцию MVC?

Ответ -> Это не«т!
Ну, это так, но не полностью.
Это потому, что MVC - это подход, разработанный в конце 1970-х для языка программирования Smalltalk-80.В то время графические интерфейсы и персональные компьютеры были довольно редки, а всемирная паутина даже не была изобретена!Большинство современных языков программирования и IDE были разработаны в 1990-х годах. В то время компьютеры и пользовательские интерфейсы полностью отличались от тех, что были в 1970-х годах.
Об этом следует помнить, когда говорите о MVC.
Мартин Фаулер написал очень хорошую статью о MVC, MVP и современных графических интерфейсах.

Answer 2

Бизнес-правила входят в модель.

Скажем, вы отображали электронные письма для списка рассылки.Пользователь нажимает кнопку «удалить» рядом с одним из электронных писем, контроллер уведомляет модель об удалении записи N, а затем уведомляет представление об изменении модели.

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

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

Answer 3

Термин бизнес-логика, на мой взгляд, не является точным определением.Эванс рассказывает в своей книге «Управление через домен» о двух типах бизнес-логики:

• Доменная логика.
• Прикладная логика.

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

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

Для обоих этих типов приложений импорт / экспорт CSV может иметь значение, но правила импорта / экспорта CSV не имеют никакого отношения к реальному домену.Этот вид логики является прикладной логикой.

Доменная логика, безусловно, входит в уровень модели.Модель также будет соответствовать доменному уровню в DDD.

Однако логику приложения не обязательно размещать на уровне модели.Это может быть помещено непосредственно в контроллеры, или вы можете создать отдельный прикладной уровень, содержащий эти правила.Что наиболее логично в этом случае, будет зависеть от реального применения.

Answer 4

A1 : бизнес-логика переходит в Model часть в MVC.Роль Model должна содержать данные и бизнес-логику.Controller, с другой стороны, отвечает за получение данных от пользователя и решение, что делать.

A2 : A Business Rule является частью Business Logic.У них has a отношения.Business Logic имеет Business Rules.

Взгляните на Wikipedia entry for MVC.Перейдите к разделу «Обзор», где упоминается поток шаблона MVC.

Также посмотрите на Wikipedia entry for Business Logic.Упоминается, что Business Logic состоит из Business Rules и Workflow.

Answer 5

Это ответ на вопрос, но я дам свой «один цент»:

Бизнес-правила принадлежат модели. «Модель» всегда состоит из (логически или физически разделенных):

• модель представления - набор классов, которые хорошо подходят для использования в представлении (оно приспособлено для конкретного пользовательского интерфейса / презентации),
• модель домена - независимая от интерфейса часть модели, а
• репозиторий - часть "модели", учитывающая хранение.

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

Answer 6

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

Многоуровневая архитектура включает разбиение приложения на уровни / уровни (например, представление, бизнес-логика, доступ к данным)

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

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

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

Answer 7

Нет смысла помещать ваш бизнес-уровень в модель для проекта MVC.

Скажи, что твой босс решит сменить слой презентации на что-то еще, ты бы облажался! Бизнес-уровень должен быть отдельной сборкой. Модель содержит данные, которые поступают из бизнес-уровня, который передается в представление для отображения. Затем при публикации, например, модель связывается с классом Person, который находится на бизнес-уровне, и вызывает PersonBusiness.SavePerson (p); где p - класс Person. Вот что я делаю (класс BusinessError отсутствует, но будет добавлен и в BusinessLayer):

Answer 8

Q1:

Бизнес-логику можно рассматривать в двух категориях:

1. Доменная логика, такая как управление адресом электронной почты (уникальность, ограничения и т. Д.), Получениецена продукта для выставления счета или расчет общей цены shoppingCart на основе его объектов продукта.

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

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

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

Дело в том, что примечания, упомянутые «грязью» и «Фрэнком» выше, могут быть как истинными, так и «Питом» (бизнес-логику можно поместить в модель,или контроллер, в соответствии с типом бизнес-логики).

Наконец, обратите внимание, что MVC отличается от контекста к контексту.Например, в приложениях для Android предлагаются альтернативные определения, которые отличаются от веб-определений (см., Например, post ).

---

Q2:

Бизнес-логика является более общей, и (как упоминалось выше как «дециклон») мы имеем следующее соотношение между ними:

бизнес-правила ⊂ бизнес-логика

Answer 9

Модель = код для операций с базой данных CRUD.

Контроллер = отвечает на действия пользователя и передает пользовательские запросы на получение данных или удаление / обновление модели, в соответствии с бизнес-правилами, специфичными для организации. Эти бизнес-правила могут быть реализованы в вспомогательных классах или, если они не слишком сложны, просто непосредственно в действиях контроллера. Контроллер наконец просит представление обновить себя, чтобы предоставить пользователю обратную связь в виде нового дисплея или сообщения типа «обновлено, спасибо» и т. Д.,

View = UI, сгенерированный на основе запроса к модели.

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