Шаблон Page Controller. Выводы

Опубликовал read-php в 17.02.2011 Категория: Шаблоны корпоративных приложений PHP

У этого подхода есть огромное преимущество: он сразу понятен любому, у кого есть хотя бы минимальный опыт создания веб-приложений. Мы делаем запрос на вывод перечня заведений и именно это получаем. Даже ошибка находится в ожидаемых пределах, поскольку проблемы типа «Server error» и «Page not found»—это ежедневная реальность.

Но ситуация становится немного более сложной, если вы отделяете представление от класса Page Controller, однако тесная взаимнооднозначная связь между участниками достаточно очевидна.

Сфера, которая довольно сложна для понимания, — это включение представлений. Контроллер страницы (PageController) по окончании работы включает свое представление. Но в некоторых ситуациях он может использовать тот же код включения, чтобы включить другой контроллер страницы. Поэтому, например, когда AddVenue успешно добавляет заведение, то больше не нужно отображать форму для ввода данных. Поэтому полномочия делегируются другому контроллеру страницы с именем Listvenues. Вы должны ясно представлять себе, когда делегируете полномочия представлению, а когда— другому контроллеру страницы. Это обязанность контроллера страницы— гарантировать, что его представления будут иметь необходимые для работы данные.

Хотя класс контроллера страницы (PageController) может делегировать полномочия объектам типа Command, преимущество этого не так заметно, как в случае шаблона Front Controller. Классы Front Controller должны сначала определить, какова цель запроса, а классы Page Controller уже это знают. Небольшая проверка параметров запроса и вызовы логики приложения, которые вы бы поместили в класс Command, так же легко помещаются в класс контроллера страницы. И вы сможете извлечь преимущество из того факта, что вам не нужен механизм выбора объектов типа Command.

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

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

Но невозможно начать с Page Controller и двигаться к шаблону Front Controller. Это особенно верно, если вы используете суперкласс PageController.

Как правило, если, по моим оценкам, мне нужно меньше недели для завершения разработки системы и в будущем ее не придется расширять, я выбираю шаблон Page Controller и пользуюсь преимуществом быстрого выполнения проекта. Если же я создаю крупный проект, который имеет сложную логику представлений и со временем будет расширяться, то неизменно останавливаю свой выбор на шаблоне Front Controller.

Комментариев нет

Добавить комментарий