Приступая к работе
Работая с Zend Framework, понимаеш, что нужно очень грамотно строить свои приложения, ведь, если честно сознаться этот фреймворк расходует немало ресурсов, поэтому нужно уметь оптимизировать и экономить. Очень много программистов, которые используют Zend Framework, нагружают его немелким довеском — Smarty. Именно о таком программировании пойдёт речь…
Приступим!
Работая над веб-сайтами, для разделения логики и представления я использовал шаблонизатор Smarty. Потом, когда дело дошло до разработки сложного и более крупного проекта, я понял, что Smarty меня больше не устраивает. Постоянно путаешся с закрытием конструкций Smarty и когда всё-таки вылетает ошибка неможеш найти место, где этот тег небыл закрыт. И не каждый дизайнер сможет работать со Smarty — приходится делать всё это самому. Надоело заключать каждую скобку Javascript'a в {literal}, надоело искать ошибки в огромном шаблоне с кучей условий и циклов!
Вдобавок ко всему прибавляем «вес» Смарти. Да, вы скажете, что в Смарти отлично реализована система
кэширования, однако одна подгрузка библиотки Smarty.class.php с кучей
инклудов и плагинов при каждой загрузке страницы занимает существенную
часть времени от загрузки всей страницы.
И тут приходишь к выводу – а зачем было вообще изобретать велосипед? PHP сам по себе, как язык, является мощным шаблонизатором, и разработчики изначально уже заложили в него этот функционал.
Кроме того, синатаксис у PHP куда более приятный и удобный, нежели у Smarty. Скажете, что со Smarty гораздо удобнее работать верстальщикам? Да ничего подобного. Из личного опыта скажу, что в 90% случаев к программисту приходит сверстанный html-шаблон, который далее уже «прикручивает» сам программист. А если уж есть компетентные верстальщики, которые были способны брать всю view-логику на себя, то думаю им не составит труда вместо тех же {if} писать <?php if () {?>.
Но как только представляешь, как много ты выигрываешь по производительности, скорости разработки, скорости отладки и поиска ошибок — хочется выбросить Smarty навсегда и забыть о нем.
При
этом используя Zend Framework, можно написать и своё кеширование,
которое еще в несколько раз ускорит работу нашего приложения. Так зачем
же изобретать велосипед?
Умелый программист таким образом грамотно разделит логику от представления, сделает механизмы кеширования и приложение будет просто «летать».
А используя короткие
конструкции РНР, можно добится наглядности в Ваших шаблонах вида, хотя
стандарты кодирования с помощью Zend Framework требуют использования
полных, С-подобных конструкций РНР. Ну это совсем уж Ваше дело, главное
что я Вас предупредил 
Dune 
на вашем блоге. Что такое?? ZF это жн почти C++ ?? Где ваше быстродействие
Вы глубоко заблуждаетесь. Разве легче писать конструктор для получения данных из базы, чем просто написать mysql_qyery('SELECT something FROM table WHERE statement'). Также груда длинных переменных, названий функций и т.д. Что это упрощает разработку? Вы проведите обзор СМС на базе ZF и увидите что у них разная структура каталогов, похожие конструкторы имеют разные имена, у одних xml у других ini в качестве конфигов. Где тот общий принцип программирования ради которого и появился на свет ZF. Я согласен что это дело вкуса, но уникальное и быстрое ПО на ZF строить я бы нерекомендовал. Если вспомните архитектуру CPU то увидите что самые динные операции это операции прыжков (jump), операции вызовов (call), в php это require, include, require_once, eval, всевозможные вызовы пользовательских функций, тем более внутри классов. Этим более чем достаточно насыщен ZF. Да для маленьких сайтов может ZF и отличное решение, но для больших порталов, для сложной иерархии каталогов, со сложными БД, если сайт хорошо продвигается и идет тенденция роста трафика ZF не взлетает.