Application Controller в CMF: избыточность экземпляров данного паттерна

[xconfigurator]

Application Controller в CMF: избыточность экземпляров данного паттерна

Приветствую, народ, прошу разъяснить некоторые моменты.

При пректировании CMF, решил использовать новую модную вариацию MVC с Front/Application контроллерами.

С Front Controller всё как-бы понятно, основную ф-ность характеризовать как:
1. Инициализация и вызов цепочки Interception Filter

2. Получение объекта Application Controller посредством некой фабрики, и делегирование ему последующей обработки контекста (Request|Responce Context)

естественно, можно добавить ещё чего-то по-вкусу, но из основной ф-ности как бы всё


Обязанности Application Controller-а же, мне представляются следующим образом:
1. На основе распарсенного URL полученного из Request Context, используя некую Command Factory создаём объект конкретной комманды для обработки этого запроса (Action)
2. управление уровнем Представления (шаблонизация, passive/active view, transform/template view etc) Впринципе, кто создаёт конкретный View, здесь не важен - это может быть Command(Action) - как классический пример, либо же Application Controller

вот собственно и всё...

Вопрос
1.
Если создание конкретной Команды (Action), происходит средствами Абстракной Фабрики (Command Factory) на основе, например конфига, динамически выбираемой Стратегии (Strategy), зачем вообще нужен дополнительный уровень абстракции - Application Controller
Ведь все те же действия, могут осуществляться в Front Controller, с тем жу уровнем АБСТРАКЦИИ (гибкости), как и в Application Controller (так как конкретные объекты, реализующие Бизнес-Логику создаются Абстрактными фабриками - т.е. Command[/b] создаётся Command Factory)
- для чего тогда нужен этот самый Application Controller (отдельная абстрактная сущность).
- Кто их реально использует в своих CMF
- Как Вы их используете

2

Непонятно (видимо, из-за неразрешённого вопроса №1), сколько должно быть этих самых Application Controller (мда, звучит глуповато - поясню на примере)

Допустим имеем некий сайт, на нашем CMF, у сайта существуют такие сервисы (компоненты и т.п)
- Новости
- Каталог чего-то (например продукции)
- Книга отзывов

всё это живёт под нашим CMF, который использует Front Controller для Маршрутизации к конкретному сервису (новости, отзывы), и Application Controller - для создания Объекта Command (Action) обрабатывающего этот запрос

Теперь, URL типа : http://somesite.com/news/view/2006/11/13
"Декомпозируется" объектом Context и является "Картой" для Front Controller, какой Application Controller нужно создать (на это указывает часть news, т.е. нечто вроди:

...
#require_once(LIB_ROOT_PATH.'/news/web_app_controller.php');
$appCtrl = new WebApplocationController($context);
....

и для Application Controller указывает, какая команда (Command/Action) должны создаваться (на это указывает view)

В этом примере, все указания, какой именно объект должен создаваться берутся из URL (после, маппинг с конфига и проч.), т.е. один клас Application Controller (в данном случае WebApplicationController) может создавать конкретные Команды для каждого из сервисов (новости, каталог, форум, магазин да что угодно)

- Для чего тогда нужно несколько экземпляров подклассов application Controller
например NewsWebAppController, ShopWebAppController и т.д.
- Кто как делает в своих CMF
- Что Вы считаете по поводу необходимости/ненужности подклассов пораждённых от WebAppController

Вобщем, всем, кто потратив время, дочитал до этих строк - большое спасибо! Вы мне очень поможите, если попробуете объяснить непонятные мне моменты!

 

[whirlwind]

Use an Application Controller to centralize retrieval and invocation of request-processing components, such as commands and views

Он д.б. один. NewsWebAppController и ShopWebAppController это target, хотя я его называю контроллер (страницы).

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

Если говорить о MVC, то ИМХО, его нужно разрабатывать изнутри, а не снаружи, отделяя менее зависимые абстракции от более зависимых: app ctrl не сможет работать без target, работа target зависит от принципа view (например хелперы для активных шаблонов, контроллеры для пассивных и т.п.). Какая разница, будет-ли снаружи "матрешка", если контроллер страницы работает не верно или имеет кривую структуру?

 

[xconfigurator]

Спасибо за ответ!
Можно тогда попросить с разъяснения простых вещей (дабы не войти в заблуждение и не начать неправильно понимать эти принципы, на самом корню)

Front Controller - экземпляр этого класса (или точнее этот класс, так как обычно он static) на весь "сайт" один

Application Controller - экземляр этого же класа либо один, либо сужествует наследник для некоторых конкретных Сервисов

- какой фреймвёрк использует сразу эти оба паттерна (наилучший так сказать фреймвёрк в этом плане)

 

[whirlwind]

Честно говоря, я лезу в паттерны только когда решаю нетривиальные задачи. Для типовых задач паттерны все равно одни, хотя называть их можно как угодно. Для себя же я нашел наиболее удобный MVC: есть контейнер (контроллер) и экшены. Это позволяет сосредоточить код в более-менее ограниченном количестве классов, а не размазывать его по и без того абстрактному и неоднозначному трактованию MVC. Вот так у меня выглядит код рядовой страницы

include_once("init.php");
include_once("controller/admin/fa_advert.class.php");

$output = new Out_Smarty;
$output->smarty->template_dir = SMARTY_TEMPLATE_DIR;
$output->smarty->compile_dir = SMARTY_COMPILE_DIR;
$input = new In_HTTP;

$c = new FA_Advert;

if ( !$user->isUserInGroup(array("admin","manager")) ){
	$template = "no_access";
}else{
	$c->enableInputProcessing();
	$c->run($input,$output);
	$template = "reference/advert";
}
$o->smarty->display($template.".tpl");

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

>- какой фреймвёрк использует сразу эти оба паттерна (наилучший так сказать фреймвёрк в этом плане)

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

PS. поправил код, для полноты картины

 

[xconfigurator]

Автор оригинала: whirlwind

>- какой фреймвёрк использует сразу эти оба паттерна (наилучший так сказать фреймвёрк в этом плане)

Так а фв выбирается по принципу - в котором больше крутых паттернов?

Нет, мне это нужно, только что бы понять функциональность, возложенную на каждый из этих контроллеров (Фронт/ Апп) на конкретных примерах. Просто для того, что бы правильно понимать эти паттерны.

К тому же не нужно забывать, что интерактивные и веб-приложения довольно-таки сильно разняться, по этому Java-вские паттерны не так то легко приспособить.

Да, но именно эти 2а паттерна, как раз из разряда Web Presentation, как по Фаулера, так и от самих Sun (Core J2EE Patterns)

 

[whirlwind]

Насколько я понял, это одно и то же. Достаточно посмотреть схемы от тех и тех.

Или точнее можно так: считай что Front Controller это Target в Application Controller

 

[xconfigurator]

Понятие Диспетчеризации/форвардинг (Dispatch/Forward) в Front Controller

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

во многих фреймвёрках (symphony, zend и т.д. "целая куча") используется понятие Диспетчерезации, в случае передачи управления одной Командой (Command/Action) другой.

Т.е. любой Action может вернуть в Фронт Контроллер некий "Токен Маршрутизации" (термин из Zend FW), который указывает, какую следующую Команду (Action) Фронт Контроллер должен вызвать.

Собственно, не понятно мне здесь следующее - зачем форвардить управление одной комманде из другой? Это етсь некая имплиментация Composite Entity или что-то ещё?

например, для URL-а http://somesite.com/news/view/2006/14

Action-ом является сущность View_Action в модуле Controller_News (здесь, Controller_News может выступать в роли Application Controller... я правильно понимаю?)

тогда зачем команде View_Action форвардить управление другой команде???

Вобщем, для чего нужен форвардинг в командах (Actions)

Чисто для информативных целей - Как называется этот паттерн с форвардингом управления командой команде (если эта техника им является)

 

[zerkms]

xconfigurator

тогда зачем команде View_Action форвардить управление другой команде???

а затем, что после у тебя может быть ещё вывод информации. те же баннера или статистика

-~{}~ 14.11.06 18:26:

Чисто для информативных целей - Как называется этот паттерн с форвардингом управления командой команде (если эта техника им является)

chain of responsibility если не ошибаюсь, хотя по идее там цепочка выстраивается до выполнения, а не во время....

 

[syfisher]

Автор оригинала: xconfigurator
Вобщем, для чего нужен форвардинг в командах (Actions)

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

-~{}~ 14.11.06 12:20:

Автор оригинала: xconfigurator
Можно тогда попросить с разъяснения простых вещей (дабы не войти в заблуждение и не начать неправильно понимать эти принципы, на самом корню)
Front Controller - экземпляр этого класса (или точнее этот класс, так как обычно он static) на весь "сайт" один
Application Controller - экземляр этого же класа либо один, либо сужествует наследник для некоторых конкретных Сервисов
- какой фреймвёрк использует сразу эти оба паттерна

Кратко как дело обстоит в Limb в пакете WEB_APP.

FrontController представлен цепочкой фильтров. Один из фильтров - это фильтр, разбирающий запрос, он определяет, какой ApplicationController (у нас это просто lmbController или его наследник) должен отрабатывать. В этой же цепочке могу стоять фильтры кеширования, фильтры проверки общих прав доступа и т.д. Меняем фильтры - меняем все приложение: можно сменить механизм разбора запроса, механизм кеширования и т.д. FrontController в виде цепочки фильтров себя оправдал на 100%

Одним из последних фильтров идет lmbActionPerformingFilter, который запускает конктерный контроллер (как бы ApplicationController) и его действие. Например, по запросу /news/edit/13 будет запущен NewsController , с действием edit. В зависимости от класса контроллера будет вызван метод performEdit или же запущем еще один объект, например, класс NewsEditCommand (паттерн Command). Правда многое зависит от конфигурации цепочки фильтров, но так работает по-умолчанию.

ApplicationController может быть выполнен как в Rails, когда каждое действие - это метод класса, или же можно использовать делигирование командам, ну или комбинирование двух способом (уже менее наглядно). Все контроллеры поддерживают единый интерфейс с методами setCurrentAction($action_name), performAction().

Чем удобно использовать общий ApplicationController:
1) Обычно туда переносится утилитарный код, также код, общих для некоторых действий.
2) Можно также создать базовый контроллер для контроллеров новостей, документов и т.д., если им присуще какое-либо общее поведение. Как бы способ устранения дублирования кода.

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

 

[xconfigurator]

Вобщем, основные моменты прояснились, благодарю всех за посильную помощь!

 

[tf]

Теперь, URL типа : http://somesite.com/news/view/2006/11/13
"Декомпозируется" объектом Context и является "Картой" для Front Controller, какой Application Controller нужно создать (на это указывает часть news, т.е. нечто вроди:

>>это указывает часть news,
ой не нравится мне это

 

[xconfigurator]

такой прямой пример был просто для простоты и наглядности... решение принимается на основе конфига и "раутера", где собственно все правила по маппингу урлов и описываются.

или я не правильно понял, что именно не нравится