Жирные модели и тощие контроллеры звучат как создание моделей Бога

Я читал много блогов, которые пропагандируют толстые модели и тощие контроллеры, особенно. лагерь Rails. В результате маршрутизаторы в основном просто выясняют, какой метод вызывать, какой контроллер и весь метод контроллера выполняет вызов соответствующего метода на модели, а затем отображать представление. Поэтому у меня есть две проблемы, которые я не понимаю:

  • Контроллер и маршрутизатор действительно не выполняют много разных задач, кроме как просто называть метод на богоподобной модели на основе маршрута.
  • Модели делают слишком много. Отправка электронной почты, создание связей, удаление и изменение других моделей, задачи очередей и т.д. В принципе, у вас есть объекты, подобные Богу, которые должны делать все, что может или не может иметь отношение к моделированию и работе с данными.

Где вы рисуете линию? Разве это не просто попадание в образец Бога?

ОТВЕТЫ

Ответ 1

Возможно, не лучшая идея взглянуть на Rails как на основной шаблон дизайна MVC. Упомянутая структура была сделана с некоторыми присущими ей недостатками (я как-то подробно остановился на ней в в другом сообщении), и сообщество только сейчас приступило к устранению последствий. Вы можете посмотреть DataMapper2 development как первый важный шаг.

Некоторая теория

Люди, дающие этот совет, похоже, страдают от довольно распространенного заблуждения. Поэтому позвольте мне начать с этого: Модель, в современном шаблоне проектирования MVC, НЕ является классом или объектом. Модель - это слой.

Основная идея шаблона MVC - Разделение проблем, и первым шагом в нем является разделение между слоем представления и уровнями модели. Точно так же, как слой презентации разбивается на контроллеры (экземпляры, ответственные за работу с пользовательским вводом), представления (экземпляры, ответственные за логику пользовательского интерфейса) и шаблоны/макеты, а также слой модели.

Основными частями, из которых состоит слой модели, являются:

  • Объекты домена

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

  • Абстракции хранения:

    Обычно реализуется с использованием шаблона отображения данных (не путайте с ORM, которые злоупотребляют этим именем). Этим экземплярам обычно задают задачу хранения и извлечения информации в объекты домена. Каждый объект домена может иметь несколько картографов, как и несколько типов хранилищ (БД, кеш, сеанс, файлы cookie,/dev/null).

  • Услуги:

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

Есть также несколько структур, которые могут находиться в пространствах между этими группами: DAOs, единицы работы и репозитории.

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

А как насчет божеств?

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

Такие изменения могут либо вызвать некоторую немедленную реакцию, либо повлиять только на данные, которые запрашивает запрос экземпляра на уровне модели, или и то, и другое.

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

Закрывающие заметки

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

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

Для людей, которые используют PHP в качестве основного языка, этот пост может иметь значение. Это немного более длинное описание слоя модели с несколькими фрагментами кода.

Ответ 2

Если классы "model" реализованы плохо, да, ваша забота актуальна. Класс модели не должен выполнять электронную почту (задачи инфраструктуры).

Реальный вопрос - это то, что подразумевает модель в MVC. Он не ограничен классами POCO несколькими способами. Модель в MVC означает Data and Business logic. Относитесь к нему как к суперсету классических моделей POCO.

Просмотр ==== Контроллер ==== Модель --- > Уровень бизнес-процесса → Основные модели

Бросьте в сборку инфраструктуры и уровни доступа к данным и используйте инъекцию, чтобы передать это в BPL, тогда ваш процесс использует MVC, как предполагалось.

BPL может ссылаться на шаблоны UoW/Respository и выполнять бизнес-правила и вызывать функции инфраструктуры посредством инъецируемых объектов или паттерна интерфейса.

Таким образом, рекомендация держать контроллер тощим не означает, что класс "человек" в классической базовой модели должен иметь 50 методов и напрямую обращаться к электронной почте. Вы правы, думая, что это неправильно.

Контроллер может по-прежнему требоваться для создания экземпляров и ввода классов инфраструктуры в BPL или базовый уровень, если он вызван напрямую. Должен быть бизнес-уровень или, по крайней мере, классы, организующие вызовы в классах классов классических объектов. Ну, это мой "взгляд" в любом случае; -)

Для общего принятия MVC описание wiki http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller

Маленький блог, в котором говорится о "М" в MVC. http://www.thedeveloperday.com/skinny-controllers/

Ответ 3

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