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

Question

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

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

контроллер и маршрутизатор действительно не делают много разных задач кроме простого вызова метода на богоподобной модели, основанной на маршруте.

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

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

770 3

design design-patterns model-view-controller architecture god-object

3 ответов:

Comments

Ничего не найдено.

tereško · Accepted Answer · 2017-05-23 15:03:05

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

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

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

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

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

Объекты Домена

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

Хранение Абстракций:

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

услуги:

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

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

phil soady · Accepted Answer · 2012-12-26 21:29:32

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

реальный вопрос заключается в том, что означает модель в MVC. Это не ограничивается классами POCO с несколькими методами. Модель в MVC означает данные и бизнес-логику. Рассматривать его как надмножество классической модели Роко.

View = = = = контроллер = = = = модель - - - > уровень бизнес-процессов -- > ядро модели

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

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

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

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

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

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

Bryan Young · Accepted Answer · 2012-12-26 20:54:30

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