пошел учить мат. часть, как оказалось, мое представление о MVC-паттерне сходно с представлением большинства программистов с небольшим опытом, т.е. мой контроллер — это ТТУК — «Толстые тупые уродливые контроллеры» (http://ru.wikipedia.org/wiki/Model-View-Controller)
содержимое статического класса держится в памяти до смерти скрипта
Вот здесь то наверное и расходятся наши мнения, так как я считаю это неоспоримым преимуществом.
Во первых, не забываем, что мы подключаем классы со статическими методами через __autoload, т.е. их нет в памяти до первого обращения, а во вторых я предлагаю в один класс комплектовать исключительно близкие по предметной области методы, в этом случае велика вероятность, что эти же методы, или их братья по контейнеру, в текущем контроллере или модели будут использованы неоднократно, следовательно если предмет текущей логики скрипта далек от функционала определенного класса, вероятно, что он не будет инициализирован. А в вашем случае, вы можете гарантировать, что деинициализированный объект класса Вам более не пригодится? Ведь если это произойдет, будет дополнительный расход ресурсов на повторную инициализацию.
И наверное в контексте общей темы топика я приведу еще один пример, который и был инициатором всей этой затеи, но потом ушел из зоны внимания — скрипт крон-менеджера. Его архитектура не базируется на паттерне MVC, так как ни контроллера ни тем более представления в нем нет и быть не может, есть, грубо говоря, только модель, в одном единственном экземпляре. Но он в то же время неотъемлемая часть системы и работает со всеми теми же данными. Т.е. это приложение абсолютно иного назначения, обязанное выполнятся в контексте сайта. А применив к нему описанную технологию, мы в нем урезаем избыточность, плюс к этому появляются новые возможности для отладки и логирования на одной общей базе.
Вы правы абсолютно на 100%, но моя ошибка заключается в выборе предметной части примеров, а цель неизменна и до сих пор — описать способ, так сказать Дизайн Единой Точки входа с маршрутизацией не на уровне сервера, а на уровне программного кода.
FrontController должен быть описан в методе execute финального потомка entryPoint, это неявно подразумевается в коде.
Использование статиков не всегда оправдано — это раз.
Опять же все зависит от ситуации, например есть в проекте файл utilities.php в котором содержится 5 тысяч строк программного кода и в каждом отдельном запросе используется лишь часть его — разве классы со статиками не выход, тем более что подключаться они будут не всем скопом, а через autoload? а как Вы прокомментируете существование .net фреймворка?
При этом, ajax, json, xml и http точки входов отличаются только способом отображения (т.е. — подгружаемыми шаблонами) и их разделение — задача как раз FrontController на основе каких-либо параметров, а не Dispatcher.
Это наверное уже зависит от желания автора и конкретной задачи, понятно, что если перечисленные точки входа отличаются лишь способом отображения, то фронт-контроллера вполне хватит, но как я писал в статье, могут возникнуть концептульно несхожие задачи, и тогда выход = диспетчер.
Например есть у дилингового цента сайт и через него поставляются котировки в режиме реального времени в клиентские терминалы, причем раздача котировок достаточно активная и отдаваемые данные непосредственно связанны с данными фигурирующими на сайте, т.е. нужно принципиально новое приложение, которое имеет много связей с существующим. Я уверен, вы предложите много вариантов решения данной проблемы, вплоть до выделения этого приложения в отдельное на собственном сервере, но к примеру нагрузка еще не настолько велика и какой-нибудь большой рефакторинг просто финансово не может быть обоснован, что же делать?
Можно придумать еще очень много примеров, на которые естественно можно придумать и опровержения, но вы сами должны понимать, что программирование это весьма спорное ремесло и у каждой задачи есть не один десяток как обоснованных, так и необоснованных решений.
Огромное спасибо вам за внимание к статье, я еще раз попытаюсь переосмыслить ее и изложить ее в более качественной форме.
Вы абсолютно правы, концепция единой точки входа является основой практически всех распространенных фреймворков. На это и нацелена первая половина статьи — объяснить как это происходит, основу этого архитектурного решения, так как, как это ни парадоксально, некоторые разработчики попросту не знают, как называется этот механизм и не до конца понимают всех целей, которые им преследуются. В частности программисты возрастом менее двух профессиональных лет, а то и старше затрудняются ответить на вопрос, что такое «избыточность кода» и к чему она приводит.
Я дописал статью до конца, надеюсь во второй половине и вы найдете интересные моменты.
Вот здесь то наверное и расходятся наши мнения, так как я считаю это неоспоримым преимуществом.
Во первых, не забываем, что мы подключаем классы со статическими методами через __autoload, т.е. их нет в памяти до первого обращения, а во вторых я предлагаю в один класс комплектовать исключительно близкие по предметной области методы, в этом случае велика вероятность, что эти же методы, или их братья по контейнеру, в текущем контроллере или модели будут использованы неоднократно, следовательно если предмет текущей логики скрипта далек от функционала определенного класса, вероятно, что он не будет инициализирован. А в вашем случае, вы можете гарантировать, что деинициализированный объект класса Вам более не пригодится? Ведь если это произойдет, будет дополнительный расход ресурсов на повторную инициализацию.
И наверное в контексте общей темы топика я приведу еще один пример, который и был инициатором всей этой затеи, но потом ушел из зоны внимания — скрипт крон-менеджера. Его архитектура не базируется на паттерне MVC, так как ни контроллера ни тем более представления в нем нет и быть не может, есть, грубо говоря, только модель, в одном единственном экземпляре. Но он в то же время неотъемлемая часть системы и работает со всеми теми же данными. Т.е. это приложение абсолютно иного назначения, обязанное выполнятся в контексте сайта. А применив к нему описанную технологию, мы в нем урезаем избыточность, плюс к этому появляются новые возможности для отладки и логирования на одной общей базе.
FrontController должен быть описан в методе execute финального потомка entryPoint, это неявно подразумевается в коде.
Опять же все зависит от ситуации, например есть в проекте файл utilities.php в котором содержится 5 тысяч строк программного кода и в каждом отдельном запросе используется лишь часть его — разве классы со статиками не выход, тем более что подключаться они будут не всем скопом, а через autoload? а как Вы прокомментируете существование .net фреймворка?
Это наверное уже зависит от желания автора и конкретной задачи, понятно, что если перечисленные точки входа отличаются лишь способом отображения, то фронт-контроллера вполне хватит, но как я писал в статье, могут возникнуть концептульно несхожие задачи, и тогда выход = диспетчер.
Например есть у дилингового цента сайт и через него поставляются котировки в режиме реального времени в клиентские терминалы, причем раздача котировок достаточно активная и отдаваемые данные непосредственно связанны с данными фигурирующими на сайте, т.е. нужно принципиально новое приложение, которое имеет много связей с существующим. Я уверен, вы предложите много вариантов решения данной проблемы, вплоть до выделения этого приложения в отдельное на собственном сервере, но к примеру нагрузка еще не настолько велика и какой-нибудь большой рефакторинг просто финансово не может быть обоснован, что же делать?
Можно придумать еще очень много примеров, на которые естественно можно придумать и опровержения, но вы сами должны понимать, что программирование это весьма спорное ремесло и у каждой задачи есть не один десяток как обоснованных, так и необоснованных решений.
Огромное спасибо вам за внимание к статье, я еще раз попытаюсь переосмыслить ее и изложить ее в более качественной форме.
Я дописал статью до конца, надеюсь во второй половине и вы найдете интересные моменты.