Товсті моделі та худі контролери звучать як створення моделей Бога [закрито]

Я читав багато блогів, які захищають товсті моделі та худі контролери , особливо. табір Rails. В результаті маршрутизатори в основному просто з’ясовують, який метод викликати на якому контролері, і все, що робить метод контролера, це викликати відповідний метод на моделі, а потім відкрити вигляд. Отже, у мене тут є два занепокоєння, яких я не розумію:

1. Контролер і маршрутизатор насправді не виконують багато інших завдань, крім простого виклику методу на богоподібній моделі на основі маршруту.
2. Моделі роблять занадто багато. Надсилання електронних листів, створення взаємозв’язків, видалення та модифікація інших моделей, завдання в чергу тощо. Зараз в основному у вас є богоподібні об’єкти, які повинні робити все, що може стосуватися моделювання та роботи з даними, а може і не стосуватися.

Де ви проводите межу? Хіба це не просто впадає у зразок Бога?

_{Можливо, це не найкраща ідея розглядати Rails як основний шаблон дизайну MVC. Зазначені рамки були зроблені з деякими притаманними недоліками (я, напевно, детально розробив це в іншій публікації ), і громада лише зараз почала вирішувати наслідки. Ви можете розглядати розробку DataMapper2 як перший важливий крок.}

Якась теорія

Люди, які дають цю пораду, здається, уражені досить поширеною помилкою. Тож дозвольте мені розпочати, прояснивши це: Модель за сучасним шаблоном дизайну MVC НЕ є класом чи об’єктом.Модель - це шар.

Основною ідеєю шаблону MVC є Поділ проблем, а першим кроком у ньому є поділ між шаром презентації та шарами моделі. Подібно до того, як рівень презентації розпадається на контролери (екземпляри, що відповідають за введення користувачем), подання (екземпляри, що відповідають за логіку інтерфейсу) та шаблони / макети, так це робить і шар моделі.

Основними частинами, з яких складається шар моделі, є:

• Об'єкти домену

  Також відомий як доменні сутності, бізнес-об’єкти чи об’єкти моделі (мені не подобається це останнє ім’я, оскільки це лише додає плутанини). Ці структури люди зазвичай помилково називають "моделями". Вони відповідають за розміщення бізнес-правил (всю математику та перевірку для певної одиниці логіки домену).

• Абстракції зберігання:

  Зазвичай реалізується за допомогою шаблону зіставлення даних (не плутайте з ORM , які зловживали цією назвою). Зазвичай ці екземпляри мають завдання зберігати інформацію та отримувати її в об’єктах домену. Кожен об’єкт домену може мати декілька карт, так само як існує кілька форм зберігання (БД, кеш, сеанс, файли cookie, / dev / null).

• Послуги:

  Структури, що відповідають за логіку програми (тобто взаємодія між об’єктами домену та взаємодія між об’єктами домену та абстракціями сховища). Вони повинні діяти як "інтерфейс", за допомогою якого рівень презентації взаємодіє з шаром моделі. Зазвичай це те, що в Rails-подібному коді потрапляє в контролери.

Існує також кілька структур, які можуть бути в просторах між цими групами: DAO , одиниці роботи та сховища .

_{О ... і коли ми говоримо (в контексті Інтернету) про користувача, який взаємодіє з додатком MVC, це не людина. "Користувач" - це насправді ваш веб-браузер.}

То як щодо божеств?

Замість того, щоб мати якусь страшну та монолітну модель для роботи, контролери повинні взаємодіяти зі службами. Ви передаєте дані від вводу користувача певній службі (наприклад, MailServiceабо RecognitionService). Таким чином контролер змінює стан модельного рівня, але це робиться за допомогою чіткого API і не возитися з внутрішніми структурами (що може спричинити негерметичну абстракцію).

Такі зміни можуть або викликати негайну реакцію, або впливати лише на дані, які екземпляр подання вимагає від рівня моделі, або на обидва.

Кожна служба може взаємодіяти з будь-якою кількістю (однак, як правило, лише декількома) абстракцій об’єктів домену та сховища. Наприклад,RecogitionService не могли б піклуватися про абстракції зберігання предметів.

Заключні примітки

Таким чином ви отримуєте додаток, яке можна протестувати на будь-якому рівні, має низький рівень зв’язку (якщо він правильно реалізований) і має чітко зрозумілу архітектуру.

Однак майте на увазі: MVC не призначений для невеликих додатків. Якщо ви пишете сторінку гостьової книги за шаблоном MVC, ви робите це неправильно. Ця схема призначена для забезпечення правопорядку у великомасштабних програмах.

_{Для людей, які використовують PHP як основну мову, ця публікація може бути актуальною. Це трохи довший опис шару моделі з кількома фрагментами коду.}

Якщо класи "моделі" реалізовані погано так, ваша стурбованість є актуальною. Клас моделі не повинен робити електронну пошту (завдання інфраструктури).

Справжнє питання полягає в тому, що означає модель у MVC. Це не обмежується класами POCO кількома методами. Модель у MVC означає дані та ділову логіку. Ставтеся до цього як до набору класичних основних моделей POCO.

Перегляд ==== Контролер ==== Модель ---> Рівень бізнес-процесів -> Основні моделі

Додайте збірки інфраструктури та шари доступу до даних і використовуйте ін’єкцію, щоб передати це в BPL, тоді ваш процес використовує MVC за призначенням.

BPL може викликати шаблони UoW / Репозиторій, а також виконувати ділові правила та викликати функції Інфраструктури за допомогою інжектованих об'єктів або скорочень інтерфейсу.

Тож рекомендація тримати контролер худим не означає, що клас «людина» в класичній Core-моделі повинен мати 50 методів і безпосередньо викликати електронну пошту. Ви праві вважаєте, що це неправильно.

Контролер все ще може вимагати створення екземплярів та введення класів Інфраструктури в рівень BPL або основний рівень, якщо його викликати безпосередньо. Має бути бізнес-рівень або принаймні класи, що організовують виклики між класами класичної об'єктної моделі. Ну, це мій "погляд" у будь-якому випадку ;-)

Для загальної інформації про MVC опис wiki http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller

Маленький блог, що розповідає про "М" у MVC. http://www.thedeveloperday.com/skinny-controllers/

Я думаю, ви можете розрізнити одну модель жиру (можливо, з назвою App або Application) та кілька моделей жиру, розбитих на логічні групи (бізнес, клієнт, замовлення, повідомлення). Останнє полягає в тому, як я структурую свої програми, і кожна модель приблизно відповідає таблиці бази даних у реляційній базі даних або колекції в базі даних документів. Ці моделі обробляють усі аспекти створення, оновлення та керування даними, що складають модель, будь то розмова з базою даних або виклик API. Контролер дуже тонкий, відповідальний за те, що виклик відповідної моделі та вибір шаблону.