Возможно, было бы не лучшей идеей рассматривать 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 / репозитория, выполнять бизнес-правила и вызывать функции инфраструктуры посредством внедренных объектов или шаблонов интерфейса.
Таким образом, рекомендация держать контроллер "тонким" не означает, что класс "person" в классической модели Core должен иметь 50 методов и напрямую вызывать Email. Вы правы, думая, что это неправильно.
Контроллер может по-прежнему потребоваться для создания экземпляров и внедрения классов инфраструктуры в BPL или базовый уровень, если вызывается напрямую. Должен быть бизнес-уровень или, по крайней мере, классы, управляющие вызовами через классы классической объектной модели. В любом случае, это моя "точка зрения" ;-)
Для общего использования MVC описание вики http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller
Небольшой блог, в котором рассказывается о букве "M" в MVC. http://www.thedeveloperday.com/skinny-controllers/
источник
Я думаю, вы можете провести различие между одной толстой моделью (возможно, названной "Приложение" или "Приложение") и несколькими толстыми моделями, разбитыми на логические группы (Бизнес, Клиент, Заказ, Сообщение). Последнее - это то, как я структурирую свои приложения, и каждая модель примерно соответствует таблице базы данных в реляционной базе данных или коллекции в базе данных документов. Эти модели обрабатывают все аспекты создания, обновления и управления данными, составляющими модель, независимо от того, обращаются ли они к базе данных или вызывают API. Контроллер очень тонко отвечает за то, что вызывает соответствующую модель и выбирает шаблон.
источник