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

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

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

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

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

Он говорит:

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

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

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

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

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

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

уровень представления: Model-View-Controller

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

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

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

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

Это трюк...Надеюсь, это поможет...

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

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

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

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

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

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

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

для обоих этих типов приложений импорт/экспорт 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.

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

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

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

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

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

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

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

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

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

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

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

Вопрос 1:

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

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

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

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

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

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

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

Вопрос 2:

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

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

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

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

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

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