Ок, а есть реальные примеры того, где это реально нужно? DI призван вынести всю инициализацию в одно место, а ваша идея предполагает часть инициализации сервиса перенести в вызывающий код.
Пассаж про orm не в кассу вообще. Орм это не построитель запросов в бд. Это в первую очередь маппер между строками таблицы и объектами, а запросы на выборку относятся к orm постольку поскольку.
В Symfony DI контейнер компилируемый — то есть многие из операций выполняются один раз при прогреве кеша (или компиляции контейнера). И в рантайме, например, не используется обход всех инициализаторов, дабы понять какой из них может проинициализировать этот сервис. Контейнер компилируется в очень оптимальный с точки зрения производительности код.
Причём ручное DI также можно использовать — но оно будет не быстрое.
Странно как то. Вызывать при каждом запросе кучу кода вида if $service instanceof InterfaceName в случае с инициализаторами.
Вообще спасибо вам за статью, до неё я немного переживал что не пробовал Zend Framework толком, всё на Symfony2 сижу. Сейчас я вижу что как минимум компонент Symfony Dependency Injection спроектирован лучше чем аналогичный в Zend.
Ну всё что вы сейчас описали очень хорошо делается на компонентах симфони. И события у них есть, и результаты работы контроллеров в разные блоки вставлять можно. Видимо у вас просто не было человека с опытом работы в симфони ;)
Я это к чему всё — у меня тоже есть (и продолжается) перевод старого (2007 год) проекта на рельсы симфони. И пока ещё ни разу не довелось жалеть о содеянном :)
А что касается последнего абзаца:
1. Сроки внедрения существующих симфони-компонент, КМК, вполне сопоставимы с разработкой аналогов
2. Поддержка — код симфони-компонент покрыт тестами, + ими пользуются много разработчиков.
3. Уровень вхождения — по симфони есть отличная готовая документация, по внутренним фреймворкам их часто нет :(
Я это всё видел. Тот «оверхед», который вы привели — это просто песчинка в общем времени приложения. И экономия на этих песчинках точно не стоит чтобы велосипедить своё.
у нас отрисовка данных (шаблонизация) осуществляется в последний момент
Хм, отрисовку данных в HttpKernel можно отложить на самый последний момент с помощью StreamedResponse класса.
А также сборкой разных блоков занимается сам Application при помощи объектов Layout.
Сборка разных блоков — это же шаблонизация. У вас шаблонизацией занимается Application?
И ещё. Наверно «сборка разных блоков» подразумевает вывод в определенное место шаблона контент, который сгенерирован другим контроллером и представлением. В HttpKernel это опять же есть из коробки — Fragment называется.
В процессе работы приложение генерирует события «Получен запрос», «Найден контроллер», «Получены данные», «Поймано исключение», «Рендеринг данных», «Получен ответ».
Вот эта часть один-в-один компонент Symfony HttpKernel. И я не понимаю зачем вы сделали свой велосипед.
А кем вы работаете, что вы видели много кода, закрытого с помощью zend guard? Просто может быть специфика вашей деятельности такова, что к вам попадали только «плохие» проекты? Ну может «хорошим» проектам просто не нужны ваши услуги, вот вы их и не видели?
Причём ручное DI также можно использовать — но оно будет не быстрое.
В Zend DI (ServiceLocator) есть что-то похожее?
Вообще спасибо вам за статью, до неё я немного переживал что не пробовал Zend Framework толком, всё на Symfony2 сижу. Сейчас я вижу что как минимум компонент Symfony Dependency Injection спроектирован лучше чем аналогичный в Zend.
Таки есть. doctrine-orm.readthedocs.org/en/latest/tutorials/override-field-association-mappings-in-subclasses.html
Я это к чему всё — у меня тоже есть (и продолжается) перевод старого (2007 год) проекта на рельсы симфони. И пока ещё ни разу не довелось жалеть о содеянном :)
А что касается последнего абзаца:
1. Сроки внедрения существующих симфони-компонент, КМК, вполне сопоставимы с разработкой аналогов
2. Поддержка — код симфони-компонент покрыт тестами, + ими пользуются много разработчиков.
3. Уровень вхождения — по симфони есть отличная готовая документация, по внутренним фреймворкам их часто нет :(
Хм, отрисовку данных в HttpKernel можно отложить на самый последний момент с помощью StreamedResponse класса.
Сборка разных блоков — это же шаблонизация. У вас шаблонизацией занимается Application?
И ещё. Наверно «сборка разных блоков» подразумевает вывод в определенное место шаблона контент, который сгенерирован другим контроллером и представлением. В HttpKernel это опять же есть из коробки — Fragment называется.
Вот эта часть один-в-один компонент Symfony HttpKernel. И я не понимаю зачем вы сделали свой велосипед.