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

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

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

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

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

Он говорит:

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

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

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

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

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

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

---

уровень представления: Модель-Вид-Контроллер

---

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

---

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

---

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

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

Вот в чем фокус...Надеюсь, это поможет...

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

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

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

термин бизнес-логика на мой взгляд не совсем точное определение. Эванс рассказывает в своей книге "доменный Дизайн" о двух типах бизнес-логики:

• логики домена.
• логики приложения.

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

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

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

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

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

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.

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

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

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

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

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

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

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

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

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

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

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

Вопрос 1:

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

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

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

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

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

дело в том, что заметки, упомянутые "Mud" и "Frank" выше, могут быть истинными, а также "Pete"(бизнес-логика может быть помещена в модель или контроллер, в зависимости от типа бизнес-логики).

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

---

Вопрос 2:

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

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

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

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

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

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