У меня есть 2 вопроса:
Q1. Где именно "бизнес-логика" лежит в шаблоне MVC? Я запутался между моделью и контроллером.
Q2. Является ли "бизнес-логика" такой же, как "бизнес-правила"? Если нет, в чем разница?
Было бы здорово, если бы вы могли объяснить небольшим примером.
Бизнес-правила входят в модель.
Скажите, что вы показывали электронные письма для списка рассылки. Пользователь нажимает кнопку "удалить" рядом с одним из писем, контроллер уведомляет модель о удалении записи N, а затем уведомляет вид, который изменила модель.
Возможно, письмо администратора не должно удаляться из списка. Это бизнес-правило, что знание принадлежит модели. Представление может в конечном итоге каким-то образом представить это правило - возможно, модель предоставляет свойство IsDeletable, которое является функцией бизнес-правила, так что кнопка удаления в представлении отключена для определенных записей - но само правило не содержится в представлении.
Модель в конечном счете является привратником для ваших данных. Вы должны быть в состоянии проверить свою бизнес-логику, не касаясь пользовательского интерфейса.
Кулак всего:
Я полагаю, что вы смешиваете шаблон 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 и современных графических интерфейсах.
Термин бизнес-логика, на мой взгляд, не является точным определением. Эванс говорит в своей книге 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.
Это ответ на вопрос, но я дам свой "один цент":
Бизнес-правила принадлежат модели. "Модель" всегда состоит из (логически или физически разделенных):
Бизнес-правила, действующие в модели домена, отображаются в форме, подходящей для презентации, к модели "представления" и иногда дублируются (или также принудительно) в "слое данных".
Как уже говорилось в нескольких ответах, я считаю, что есть некоторое недопонимание архитектуры многоуровневого и MVC.
Многоуровневая архитектура включает разбиение вашего приложения на уровни/уровни (например, презентация, бизнес-логика, доступ к данным)
MVC - это архитектурный стиль для уровня представления приложения. Для нетривиальных приложений бизнес-логика/бизнес-правила/доступ к данным не должны размещаться непосредственно в моделях, представлениях или контроллерах. Для этого нужно было бы разместить бизнес-логику в своем слое презентации и тем самым уменьшить повторное использование и поддержку вашего кода.
Модель является очень разумным выбором для размещения бизнес-логики, но лучший/более удобный подход заключается в том, чтобы отделить ваш уровень презентации от уровня бизнес-логики и создать уровень бизнес-логики и просто вызывать уровень бизнес-логики из ваших моделей при необходимости. Уровень бизнес-логики, в свою очередь, вызовет уровень доступа к данным.
Я хотел бы отметить, что не редко удается найти код, который смешивает бизнес-логику и доступ к данным в одном из компонентов MVC, особенно если приложение не было архивировано с использованием нескольких уровней. Однако в большинстве корпоративных приложений вы обычно найдете многоуровневые архитектуры с архитектурой MVC на уровне презентации.
Не имеет смысла размещать ваш бизнес-уровень в модели для проекта MVC.
Скажите, что ваш босс решает изменить слой презентации на что-то еще, вы будете ввернуты! Бизнес-уровень должен быть отдельной сборкой. Модель содержит данные, которые поступают из бизнес-уровня, который переходит к отображаемому виду. Затем, например, в post, модель привязывается к классу Person, который находится на бизнес-уровне и вызывает PersonBusiness.SavePerson(p); где p - класс Person. Здесь то, что я делаю (класс BusinessError отсутствует, но также входит в BusinessLayer): 
Q1:
Бизнес-логику можно рассматривать в двух категориях:
Доменные логики, такие как элементы управления на адресе электронной почты (уникальность, ограничения и т.д.), получение цены продукта для счета-фактуры или вычисление общей цены покупки на основе его товарных объектов.
/li >Более широкие и сложные рабочие процессы, которые называются бизнес-процессами, например, контроль процесса регистрации для учащегося (который обычно включает в себя несколько шагов и требует разных проверок и имеет более сложные ограничения).
Первая категория относится к модели, а вторая относится к контроллеру . Это связано с тем, что случаи во второй категории представляют собой широкие прикладные логики и помещают их в модель, могут смешивать модельную абстракцию (например, неясно, нужно ли нам вводить эти решения в один класс модели или другой, поскольку они связаны для обоих!).
См. этот ответ для конкретного различия между моделью и контроллером, link для очень точных определений, а также эта ссылка для хорошего Android-приложения.
Дело в том, что примечания, упомянутые выше, как "Грязь", так и "Фрэнк", могут быть истинными, а также "Пит" (бизнес-логику можно поместить в модель или контроллер в соответствии с типом бизнес-логики).
Наконец, обратите внимание, что MVC отличается от контекста к контексту. Например, в приложениях для Android предлагаются некоторые альтернативные определения, которые отличаются от веб-приложений (см. post).
Q2:
Бизнес-логика является более общей и (как упоминалось выше "дециклон" ), мы имеем следующую связь между ними:
бизнес-правила ⊂ бизнес-логика
Почему бы вам не представить сервисный уровень. тогда ваш контроллер станет стройным и более читабельным, тогда все ваши функции контроллера будут чистыми действиями. вы можете разложить бизнес-логику так, как вам нужно, на уровне сервиса. многократное использование кода является высоким. не влияет на модели и репозитории.
Модель = код для операций с базой данных CRUD.
Контроллер = отвечает на действия пользователя и передает пользовательские запросы на извлечение данных или удаление/обновление модели с учетом бизнес-правил, характерных для организации. Эти бизнес-правила могут быть реализованы в вспомогательных классах, или если они не слишком сложны, просто непосредственно в действиях контроллера. Контроллер, наконец, просит, чтобы представление обновлялось, чтобы дать обратную связь пользователю в виде нового дисплея или сообщение типа "обновлено, спасибо" и т.д.,
View = UI, созданный на основе запроса на модели.
Нет жестких и быстрых правил в отношении того, куда должны идти бизнес-правила. В некоторых проектах они входят в модель, тогда как в других они включаются в контроллер. Но я думаю, что лучше держать их с контроллером. Пусть модель беспокоится только о подключении базы данных.