LINUX.ORG.RU

Существует такой шаблон проектирования?

 ,


2

2

Изучаю php и задался вопросом, есть ли такой шаблон, работающий по следующему принципу:

  1. Получаем роут(пр. /categories);
  2. Ищем класс, соответствующий этому роуту(пр. Category) и метод(пр. getCategoryList);
  3. Отдаем результат выполнения метода в шаблон(пр. CategoryListTemplate.php);

Ответ на: комментарий от no-such-file

паттерн

Я бы хотел узнать в чем недостаток такого подхода? Он похож на mvc, но исключается контроллер. Я не понимаю, зачем нужно это промежуточное звено в виде контроллера в mvc?

Zope ()
Ответ на: паттерн от Zope

но исключается контроллер

В каком месте тут исключается контроллер?

класс, соответствующий этому роуту(пр. Category) и метод(пр. getCategoryList);

Это и есть контроллер, причём именно так оно и реализовано в 99% фреймворков.

no-such-file ★★★★★ ()
Ответ на: mvc от Zope

А модель где тогда

А модели у тебя нет, ты лепишь толстый говноконтроллер который делает всё.

получает список категорий и отдает шаблону

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

no-such-file ★★★★★ ()
Последнее исправление: no-such-file (всего исправлений: 1)
Ответ на: паттерн от Zope

Re: паттерн

… но исключается контроллер.

Распределитель же. Модель работает с данными, шаблонизатор работает с отображением данных, роутер по данным из запроса определяет, кому передать управление. Кто-то ещё должен их всех соединять, иначе один из этих троих будет занят совсем не своим делом. Так вот, этот клей и есть контроллер. А как он выглядит - дело десятое.

anonymous ()
Ответ на: комментарий от no-such-file

Строго говоря, контроллер – это то что стоит на пути данных от view к модели. Т.е. берёт данные из view (когда юзер жмёт submit формы) и модифицирует модель. Наверное, и роутер, и применение параметров фильтрации сюда же можно уложить; хотя что в этих случаях понимается под моделью – вопрос открытый.

А если вьюха не напрямую коннектится к модели (паттерном observer), а имеется специальный код, читающий модель и готовящий данные для вьюхи, этот код называется presenter, а шаблон - MVP. Хотя т.к. контроллер присутствует всегда (вьюха в принципе не знает, как обновлять модель; исключение – говно-анти-паттерн active record), то правильнее было бы называть MVPC.

Т.е. Model —> [Presenter] —> View —> Controller —> Model.

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

dimgel ★★★ ()
Последнее исправление: dimgel (всего исправлений: 4)
Ответ на: комментарий от dimgel

этот код называется presenter

А также supervising controller (т.е. сорта говна). В вебе других не бывает, потому что вьюха не может активно взаимодействовать с моделью, т.е. подобные уточнения не требуются.

подгонять реальные решения под термины – так себе затея

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

no-such-file ★★★★★ ()
Последнее исправление: no-such-file (всего исправлений: 1)