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