Бізнес-логіка в MVC [закрито]
Відповіді:
Правила бізнесу йдуть у моделі.
Скажіть, ви показували електронні листи для списку розсилки. Користувач натискає кнопку "видалити" поруч із одним із електронних листів, контролер повідомляє модель про видалення запису N, а потім повідомляє про перегляд моделі, яку змінили.
Можливо, електронну пошту адміністратора ніколи не слід видаляти зі списку. Це ділове правило, що знання належать до моделі. Представлення може в кінцевому підсумку якось представляти це правило - можливо, модель виставляє властивість "IsDeletable", яке є функцією бізнес-правила, так що кнопка видалення у представленні вимкнена для певних записів - але саме правило не міститься у виду.
Ця модель в кінцевому рахунку є воротарем ваших даних. Ви повинні мати можливість перевірити свою логіку бізнесу, не торкаючись інтерфейсу.
Кулак всіх:
Я вважаю, що ви змішуєте схему MVC та принципи дизайну на основі n-ярусу.
Використання підходу MVC не означає, що вам не слід розшаровувати додаток.
Це може допомогти, якщо ви бачите MVC більше як розширення шару презентації.
Якщо ви помістите код непрезентації всередині шаблону MVC, ви дуже скоро можете скластися складний дизайн.
Тому я б запропонував перекласти свою бізнес-логіку в окремий бізнес-шар.
Подивіться лише на це: стаття Вікіпедії про багатоярусну архітектуру В
ній написано:
Сьогодні MVC та подібні моделі-перегляд-презентатори (MVP) - це розділення моделей дизайну концернів, які застосовуються виключно до презентаційного шару більшої системи.
У будь-якому випадку ... коли мова йде про корпоративну веб-програму, дзвінки з інтерфейсу користувача на рівень бізнес-логіки повинні розміщуватися всередині контролера (презентації).
Це тому, що контролер фактично обробляє виклики до певного ресурсу, запитує дані, здійснюючи виклики до бізнес-логіки та пов'язуючи дані (модель) з відповідним поданням.
Грязь сказала вам, що правила ведення бізнесу входять у модель.
Це теж правда, але він змішав (презентаційну) модель ('M' в MVC) та модель рівня даних в основі шару дизайну додатків.
Тож справедливо розміщувати правила ведення бізнесу, пов’язані з базою даних, у моделі (шарі даних) вашої програми.
Але не слід розміщувати їх у моделі вашого структурованого шару презентації MVC, оскільки це стосується лише конкретного інтерфейсу користувача.
Ця методика не залежить від того, чи використовуєте ви дизайн, керований доменом, або підхід, заснований на сценаріях транзакцій.
Дозвольте мені уявити це для вас:
Презентаційний шар: Модель - Вид - Контролер
Бізнес-рівень: Логіка домену - Логіка додатків
Рівень даних: сховища даних - рівень доступу до даних
Модель, яку ви бачите вище, означає, що у вас є додаток, який використовує MVC, DDD та рівень даних, що не залежать від бази даних.
Це загальний підхід до розробки більшого веб-додатку підприємства.
Але ви також можете зменшити його, використовуючи простий бізнес-рівень без DDD (бізнес-рівень без логіки домену) та простий рівень даних, який записується безпосередньо в певну базу даних.
Ви навіть можете скинути весь рівень даних та отримати доступ до бази даних безпосередньо з бізнес-рівня, хоча я не рекомендую.
Ось трюк ... Я сподіваюся, що це допоможе ...
[Примітка:] Ви також повинні бути в курсі того факту, що на сьогоднішній день у додатку існує більше ніж одна "модель". Зазвичай у кожного шару програми є своя модель. Модель шару презентації є специфічним для перегляду, але часто не залежить від використовуваних елементів управління. Бізнес-рівень може також мати модель, яку називають "доменна модель". Зазвичай це випадок, коли ви вирішили використовувати підхід, орієнтований на домен. Ця "доменна модель" містить як дані, так і бізнес-логіку (основна логіка вашої програми) і зазвичай не залежить від рівня презентації. Зазвичай презентаційний рівень викликає бізнес-рівень на певному "події" (натискання кнопки тощо) для зчитування даних або запису даних на рівень даних. У шару даних також може бути своя модель, яка, як правило, пов'язана з базою даних.
Питання: як це вписується в концепцію MVC?
Відповідь -> Це не так!
Ну - це ніби так, але не повністю.
Це тому, що MVC - це підхід, розроблений наприкінці 1970-х для мови програмування Smalltalk-80. На той час графічні інтерфейси та персональні комп'ютери були досить рідкісними, і всесвітня павутина навіть не була винайдена! Більшість сучасних мов програмування та IDE були розроблені у 90-х роках. На той час комп'ютери та користувальницькі інтерфейси були абсолютно іншими, ніж у 1970-х.
Ви повинні пам’ятати про це, коли ви говорите про MVC.
Мартін Фаулер написав дуже гарну статтю про MVC, MVP та сучасні графічні інтерфейси.
Термін бізнес-логіка, на мій погляд, не є точним визначенням. У своїй книзі «Дизайн, керований доменом» Еванс розповідає про два типи бізнес-логіки:
- Логіка домену.
- Логіка застосування.
На мою думку, це розділення набагато чіткіше. І з усвідомленням того, що існують різні види ділових правил, також виникає усвідомлення того, що вони не обов'язково йдуть на одне і те ж місце.
Логіка домену - це логіка, яка відповідає фактичному домену. Отже, якщо ви створюєте облікову програму, то правила домену - це правила щодо облікових записів, проводки, оподаткування тощо. У спритному інструменті планування програмного забезпечення правила будуть такими, як обчислення дат випуску на основі швидкості та точок історії у відставанні, тощо.
Для обох цих типів застосувань імпорт / експорт CSV може бути актуальним, але правила імпорту / експорту CSV не мають нічого спільного з фактичним доменом. Цей вид логіки є логікою додатків.
Логіка домену, безумовно, переходить у шар моделі. Модель також відповідала б доменному шару в DDD.
Однак логіка програми не обов'язково повинна розміщуватися в шарі моделі. Це може бути розміщено безпосередньо в контролерах, або ви можете створити окремий рівень програми, на якому розміщені ці правила. Що найбільш логічно в цьому випадку, залежатиме від фактичного застосування.
А1 : Бізнес-логіка бере 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); де р - клас Особи. Ось що я роблю (клас BusinessError відсутній, але він також перейшов у BusinessLayer):
Q1:
Логіку бізнесу можна розглядати у двох категоріях:
Логіка домену, як контроль над адресою електронної пошти (унікальність, обмеження тощо), отримання ціни продукту за рахунок-фактура або, обчислення загальної ціни ShoppingCart на основі об'єктів продукту.
Більш широкі та складні робочі процеси, які називаються бізнес-процесами, як контроль за процесом реєстрації студента (який, як правило, включає кілька кроків і потребує різних перевірок і має більш складні обмеження).
Перша категорія переходить в модель і другий один належить до контролера . Це тому, що випадки другої категорії - це широка логіка застосувань, і розміщення їх у моделі може змішати абстракцію моделі (наприклад, незрозуміло, чи потрібно нам ставити ці рішення в той чи інший клас моделі, оскільки вони пов'язані для обох!).
Дивіться цю відповідь для конкретного розмежування моделі та контролера, це посилання для дуже точних визначень, а також це посилання для приємного прикладу Android.
Справа в тому, що нотатки, згадані "Грязями" та "Франком" вище обох, можуть бути правдивими, як і "Пітом" (бізнес-логіка може бути розміщена в моделі або контролері відповідно до типу бізнес-логіки).
Нарешті, зауважте, що MVC відрізняється від контексту до контексту. Наприклад, в додатках для Android пропонуються деякі альтернативні визначення, які відрізняються від веб-базованих (див., Наприклад, цю публікацію ).
Q2:
Бізнес-логіка є більш загальною, і (як "дециклон", зазначений вище) ми маємо таке відношення між ними:
правила бізнесу ⊂ бізнес-логіка
Чому ви не введете рівень обслуговування. тоді ваш контролер буде худорлявим і читабельнішим, тоді всі ваші функції контролера будуть чистими діями. ви можете розкласти бізнес-логіку скільки завгодно, ніж вам потрібно в сервісному рівні. повторне використання коду - висота. не впливає на моделі та сховища.
Модель = код для операцій з базою даних CRUD.
Controller = відповідає на дії користувача та передає користувачеві запити на отримання даних або видалення / оновлення до моделі відповідно до правил бізнесу, специфічних для організації. Ці бізнес-правила можуть бути реалізовані в допоміжних класах, або якщо вони не надто складні, просто безпосередньо в діях контролера. Нарешті, контролер просить перегляд оновити себе, щоб дати відгуку користувачеві у вигляді нового дисплея або повідомлення типу "оновлено, дякую" тощо.
View = інтерфейс користувача, який генерується на основі запиту на моделі.
Немає жорстких і швидких правил щодо того, куди мають дійти правила бізнесу. У деяких конструкціях вони переходять у модель, тоді як в інших вони включаються до контролера. Але я думаю, що краще тримати їх з контролером. Нехай модель турбується лише про підключення до бази даних.