>> “При подходе “$user = $users->getById($userId);” вобщем-то ничего не меняется, за исключением того, что конструкция на основе фасада: “Doctrine::getTable( ‘User’ )” заменена самописным враппером коллекции $users…”

Как же не меняется? Пропадает объектная ориентированность, одна из главных прелестей её - возможность расширения класса Пользователей, его доработки. Например буквально на днях в левом проекте (не моём, я на подхвате и вообще не на ЗФ) я расширил класс пользователя в класс Персоны и Участники (суть их не важна, но они весьма специфичны) в каждый класс добавив функционал реализующий им свойственное поведение. При этом для хранения данных используется таже таблица что и для родителя-класса Пользователи (отличаются только группы пользователей). При этом у меня весь функционал по авторизации и прочим вещам которые можно было делать с пользователями остался и в этих объектах (так нужно было по задаче). Я понимаю что все это можно сделать и на доктрин, но это будет имхо совсем не ооп, а контроллеры “растолстеют”, что не есть гуд. Либо я чего то не понимаю и доктрин provides не меньшую гибкость?

Также, насчет того что

>> “Нагромождать же поверх класса на основе ОРМ еще класс для “чистого” ООП я не решился, так как ни логики ни поведения это не меняет…”

- я считаю что любое нагромождение стоит того чтобы быть нагроможденным, если оно делает более логичной, удобной для вас, вас в перспективе, и разработчиков которые, возможно будут с этим кодом работать, структуру приложения, архитектурную его суть. Конечно если в вашей модели объекту пользователя в принципе никогда не понадобится быть чем-то более чем массивом данных… такого ваше решение, как архитектора (и вполне возможно я просто недостаточно далеко смотрю и вы правы), но я хотел высказать своё мнение по этому поводу для тех, кто может быть будет читать эту статью и пытаться сделать что-то подобное на ЗФ.

>> “А насчет подчеркиваний (_), то они мне не нравятся как пережитки РНР4, где приватных и защищенных методов и свойств просто небыло…”

Хм. никогда не думал с этой точки зрения того что это пережиток. Часто попадаются фрагменты когда пишут $this->mApples (m_Apples) типа из си люди там где можно обращаться к члену класса без $this-> ну это бред полнейший конечно. Подходы типа $this->s_AppleName имеют право на жизнь, хотя конечно просто разработчик должен быть достаточно опытен чтобы грамотно распоряжатся нетипизированностью языка, тогда в типовых приставках нет никакого смысла.
Однако… по-моему опыту работы (в основном чтение исходников зф и кода написанно по такому же принципу, поиск багов и ответов на вопросы) подчеркивания в именах переменных существенно облегчают понимание ООП структуры и делают более прозрачным сам класс, его средства и цели. Но это конечно дело субъективное.

>> “Да и стандарт оформления кода у меня вобщем-то довольно иной чем у Зенд, а подстраиваться в проекте на стандарты одной из библиотек думаю неверно…”

А я как-то не заметил особо другой разницы, поэтому подумал что с подчеркиваниями это что-то вроде недосмотра =). Чтож, просмотрю еще раз ваш код и буду ждать продолжения в надежде найти интересные и удобные решения в разработке.

* чет у меня тут заглючило, поэтому если будут дубликаты комментариев - прошу прощения.

А насчет подчеркиваний (_), то они мне не нравятся как пережитки РНР4, где приватных и защищенных методов и свойств просто небыло…
Да и стандарт оформления кода у меня вобщем-то довольно иной чем у Зенд, а подстраиваться в проекте на стандарты одной из библиотек думаю неверно…

Ещё - в зенд фреймворк везде приватные и протектед члены классов и методы начинаются с _ подчеркивания предлагаю придерживаться этого - хорошо когда все написано в одном стандарте (и ничто не заставляет вас их перемешивать)