Недавно я прочитал этот пост, который привел к ряду других сообщений, которые, похоже, предлагают ту же идею: модели делают все, View должен иметь возможность напрямую связываться с моделью и наоборот, пока контроллер остается в стороне. Однако все приведенные примеры довольно упрощены, и ни один из них не показывает пример того, как кто-то пытался реализовать полную обработку цикла запроса / ответа, что заставило меня задаться вопросом: «Должна ли модель отвечать за обработку запроса (т. Е. $ _GET, $ _POST и т. Д.)? и «должен ли контроллер работать только как сквозной проход для создания необходимой модели (моделей) и передачи модели (моделей) в представление?». (На самом деле я нашел один пример, взяв крайний смысл встраивания объекта Zend_Form в модель)
Из моего чтения того, что говорит Фаулер о MVC и просто контроллере, на первый взгляд кажется, что чем меньше уровень контроллера, тем лучше. Но потом я нашел время, чтобы вернуться и изучить то, что он говорит о MVC и Front Controller (который просто загрязняет воды, потому что оба шаблона определяют контроллеры), и теперь мои инстинкты предполагают, что Zend_Framework при реализации обоих этих шаблонов фактически создал который выполняет функции контроллера в MVC и объекты Command в Front Controller (или некоторые из них).
Поэтому мне интересно, какие общие мнения были бы у других, которые реализовали аналогичные шаблоны в своих приложениях – обрабатываете ли вы запрос полностью на уровне контроллера или вы знаете модель о параметрах запроса и обработки непосредственно в модели?
Моя первая мысль состоит в том, чтобы избежать обработки любого типа запроса в модели. Это задача диспетчера. Вот почему: предположим, что у вас есть модель, которая обрабатывает ваши запросы (GET или POST). Вероятно, эта структура будет работать хорошо. Предположим, вы хотите добавить какую-то функцию AJAX или установить в свою систему служебный интерфейс. Теперь, когда вы принимаете больше, чем просто GET / POST, то есть JSON или XML, ваша модель должна будет различать каждый тип запроса и знать, как их разобрать. Я считаю, что это разрушает много простоты и ясности кода модели. Я согласен с тем, что слой контроллера должен быть тонким, но он должен также иметь роль и опыт. Для меня опыт диспетчеров заключается в следующем:
Я колеблюсь от того, насколько точка зрения должна знать о модели. Некоторые люди рекомендуют модель идти прямо в точку зрения, но я думаю, что это хрупкая связь. Это часто приводит к логике в представлении. Кроме того, если вы работаете над проектом, в котором члены команды, работающие над представлением, не так хорошо разбираются в программировании, как основные разработчики, это ставит большую нагрузку на них, чтобы идти в ногу с изменениями. Я склонен упаковывать данные, которые я передаю своим представлениям в нейтральной структуре, а не передавать все модели.
Моя интерпретация MVC в основном прагматична. Задача модели заключается в моделировании домена, над которым вы работаете, и не должна заботиться о том, откуда поступают данные. Я часто структурирую код модели с предположением, что он может использоваться вне веб-приложения, возможно, в приложении командной строки или в настольном приложении. Такой союз редко случается, но он приводит к четкой цели каждого слоя. Задача контроллеров заключается в перемещении данных между участвующими сторонами, будь то запросы клиентов, модели или представление. Контроллер должен иметь очень небольшую логику домена, но это не значит, что у него нет никакого кода. Наконец, представление должно выглядеть просто красиво. Надеюсь, это поможет.
обработка пользовательских инструкций / ввода (например, HTTP-запросов) – это задание контроллера. модель предназначена для работы / манипуляции / получения данных, а представление – для отображения результатов для пользователя. это означает, что связь между представлением и моделью является обязанностью контроллера большую часть времени.