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

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

Немного теории

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

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

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

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

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

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

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

• Услуги:

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

Между этими группами может быть несколько структур: DAO, единиц работы и репозитории.

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

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

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

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

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

Заключительные примечания

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

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

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