Документация это всё что необходимо. По Zend она всеобъемлющая и исчерпывающая что является одним из условиев включения модулей в основной репозиторий. Если не поняли ZF из неё значит опыт работы с фреймворками в целом невелик ибо ничего радикально нового Yii, Symfony и проч. не привносят, а многое и заимствуют, как к примеру Yii из ZF.



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

Нет. У ZF2 большой порог вхождения и зачастую что бы хорошо понять определенную вещь нужно обращаться к сторонним ресурсам, если прежде с текущим вопросом сталкиваться не приходилось. И ещё раз повторюсь, это не элементарно, как утверждаете Вы, особенно когда дело доходит до практики.

Какое отношение документация имеет к репозиторию?

Вы меня читаете? Где я написал, что не понял?


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

С чем кокнретно в рамках фреймворка вы столкнулись на что нет ответа в документации? Предметно укажите ответа на какой вопрос вы не нашли в документации я ткну вас в документации прямо на этот ответ. Пока же это всё ваши субъективные мысли.

ZF претендует на промышленный стандарт в веб-разработке. И, если вы не в курсе, любые модули и расширения которые пишут под него девелоперы и которые претендуют на включение в основной репозиторий должны быть соответствующим образом документированы, что проверяется.

Далее, могу привести вам конкретный пример когда в угоду быстрой обработки запросов пишется решение обходящее логику обработки запросов и mvc-архитектуру фреймворка и предназначенное, к примеру для быстро записи/чтения из Redis. При частом возникновении подобных задач решения могут быть включены в фреймворк и расширить его. Так было со многими прикладными классами для работы к примеру с google-сервисами в том же ZF.

Я уже тебе отвечал на этот выпад, модеры удалили, не буду повторяться, надеюсь ты это читал.
Про модули от сторонних разработчиков я в курсе.
Сама документация местами ссылается на сторонние ресурсы, не нужно мне здесь сказки рассказывать.

Кроме того, прочитать описание пакета и пользоваться им а так же хорошо представлять себе его назначение не так то просто.
Некоторые пакеты активно используют патерны, без знания и понимания которых сложно понять "Как и почему это работает". После прочтения Мэтта Зандстры для подкрепления знаний в области патернов и Ромера для понимания процессов самого ZF2, мне стало намного легче.
Если без специальных знаний просто сесть за документацию и сразу все понять довольно сложная задача.


К чему это? Я против твоего утверждения что "90% фреймворка переписывается" и то что этот фреймворк элементарный.
Про обход MVC в ZF вообще речи не было. Так что пример твой был бы не к месту.

Всегда интересно, как рассуждают "а вот под высокими нагрузками все иначе, бла бла бла". И ничего, что таких проектов - дай бог 0.01% от всей разработки. Главное блеснуть ;)
Кстати, а что такое "ядро фреймворка" ;)))