Zend_Framework - где разместить обработку $ _GET и $ _POST (HTTP-запрос)?

Question

Я недавно прочитал этот пост , что привело к ряду других постов, которые, кажется, все предлагают одну и ту же идею: модели делают все, View должен иметь возможность напрямую взаимодействовать с моделью и наоборот всеми в то время как контроллер остается в стороне. Тем не менее, все показанные примеры довольно упрощены, и ни один из них не показывает пример того, как кто-то пытался реализовать полную обработку цикла запрос / ответ, что заставило меня задуматься: «Должна ли модель отвечать за обработку запроса (т.е. $ _GET, $ _POST и т. Д.) Сам? " и «должен ли контроллер действовать только как сквозной канал для создания экземпляров необходимой модели (моделей) и передачи модели (ей) в представление?». (На самом деле я обнаружил, что один из примеров - крайний случай внедрения объекта Zend_Form в модель)

Из моего прочтения того, что говорит Фаулер о MVC и просто о контроллерах в целом, на первый взгляд кажется, что чем тоньше слой контроллера, тем лучше. Но затем я нашел время, чтобы вернуться назад и изучить то, что он говорит о MVC и Front Controller (который только запутывает воду, потому что оба шаблона определяют контроллеры), и теперь мои инстинкты предполагают, что Zend_Framework при реализации обоих этих шаблонов фактически создал составной объект, который выполняет функции контроллера в MVC и объекта команды в Front Controller (или некоторых других).

Так что мне интересно, что бы общего мнения о других, которые внедрили подобные шаблоны в своих приложениях - вы обрабатываете запрос полностью на уровне контроллера или вы информируете модель о запросе и обрабатываете параметры непосредственно внутри модель?

Answer 1

Моя первая мысль - избегать обработки каких-либо запросов в модели. Это работа контроллера. И вот почему: предположим, у вас есть модель, которая обрабатывает ваши запросы (GET или POST). Эта структура, вероятно, будет хорошо работать изначально. Теперь предположим, что вы хотите добавить какую-то функциональность AJAX или установить служебный интерфейс в вашей системе. Теперь, когда вы принимаете больше, чем просто GET / POST, то есть JSON или XML, ваша модель должна будет различать каждый тип запроса и знать, как их анализировать. Я считаю, что разрушает много простоты и ясности модельного кода. Я согласен, что уровень контроллера должен быть тонким, но он также должен иметь роль и опыт. Для меня экспертиза контроллеров заключается в следующем:

1. Обработка входящих запросов
2. Данные доставки к модели
3. Запрос / принятие данных от модели
4. Передать модель данных в представление

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

Моя интерпретация MVC в основном прагматична. Работа модели заключается в модели домена, в котором вы работаете, и не должно заботиться о том, откуда поступают данные. Я часто структурирую код модели, предполагая, что он может использоваться вне веб-приложения, возможно, в приложении командной строки или в настольном приложении. Такое объединение случается редко, но оно приводит к четкой цели каждого слоя. Работа контроллеров заключается в перемещении данных между вовлеченными сторонами, будь то запросы клиентов, модели или представление. Контроллер должен иметь очень мало логики домена, но это не значит, что у него нет кода. Наконец, вид должен выглядеть красиво. Надеюсь, это поможет.

Answer 2

обработка пользовательских инструкций / ввода (например, HTTP-запросов) является задачей контроллера. Модель предназначена для работы / манипулирования / извлечения данных, а представление - для отображения результатов пользователю. это означает, что соединение между представлением и моделью в большинстве случаев является обязанностью контроллера.