И что это меняет в нашем споре? Если проект собран не на опенсорсном , а корпоративном фреймворке, там нет архитектуры и идей? Есть. И если это серьёзный проект, то их там поболе будет, идей этих. Потому что корпоративный фреймворк мобильнее по определению. Не нужно ждать официальных релизов. Как вот я сейчас с маркировкой запросов. Воткнул одну строчку и радуюсь.

Не нужно смешивать в одну кучу ORM и AR. AR, это частный случай ORM, не самый кстати лучший. Паттерн ORM в идеале ничего о базе данных знать не должен. Потому там и нет никаких запросов, а есть общие для всех объекты. Как сохранять эти объекты - вопрос второй. Может вообще в XML, а не в СУБД.

AR умеет сохранять данные самостоятельно, однако и в нем есть возможность использования различных СУБД. DAO кстати гораздо меньше подходит для унификации к СУБД, так как допускает "ручные" запросы.

Я не стану утверждать, что было раньше. Курица или яйцо. Для чего изначально разрабатывался паттерн ORM. Однако то, что он сейчас часто используется именно для унификации (как на стороне программиста, так и на стороне СУБД), это факт.

Я прекрасно знаю для чего он нужен. Потому и говорю - мне эта философия не нравится. Я не люблю "женской" логики, мне нравится логика линейная. А DI предполагает индуктивную логику, построенную на объектах, и выборе из кучи всего-всего, нужного в данный момент функционала. Почему "женская", просто тут один дядька здорово её описал. Очень подходящее объяснение принципа DI еслив чё.


Для юнит-тестов может и больше подходит, но и без DI можно спокойно их организовать. А вот что касается трассировки...
Про var_dump(), var_export(), debug_backtrace() или $exception->getTrace(); можно смело забыть, ибо там черт ногу сломит. Да и саму логику распутать не так просто бывает. На мой взгляд достаточно большая цена за облегчение юнит-тестирования. А слабая связанность решает все ту же задачу унификации. В отрыве от универсального фреймворка она как корове седло.

Но не суть, я же не навязываю. Я говорю - мне оно не подходит. А значит это в фреймворке для меня совершенно излишний функционал.

Вот именно. Плюс новый файлик. И к тем 5,5 тысячам вызовов в ZEND прибавим еще десяток. Вобщем то да, не велика разница, 5500 или 5510.

А на кой он мне тогда... Если все равно самому писать. Я уж лучше надергаю того, что нужно, из разных исходников и соберу свой самокат, приспособленный к решению конкретной, а не размазанной задачи.

Ну и мой вопрос остался без ответа. Я тут подумал на досуге, а ведь нет решения моей задачи без модификации ядра. А его трогать нельзя, если юзаешь общий фреймворк типа Yii. Или есть?

Ну, где там программисты, погулять вышли? Предложите решение. Задачка то на раз плюнуть.

_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.