Не сказал бы. В ZF, на мой взгляд, код в разы более оптимизирован. Единственное, что в нем может тормозить работу — сами ограничения ООП в php5, ибо он на 100% — ООП фреймворк.
У CI самый небольшой накладной расход из популярных PHP-фреймворков. А вот сказать, что приложение на нём быстрее, чем на Zend Framework будет нельзя. Тут уж как напишете…
В ZF есть очень тормозные компоненты, например я в одном проекте пытался использовать Zend_Locale, чтобы выводить даты в формате типа «Пятница, 24 октября 2008». Так вот, добавление этой фичи, затормозило и так не самый простой и быстрый проект в 10 (десять!) раз, потом почитал мануал и нашел, что там можно включить кэширование промежуточных результатов, т. к. там данные читаются из огромной xml, кэширование дало суммарный прирост где-то в 3 раза, но это было все равно в 3 раза медленней, чем без форматирования дат. Причем на странице было не так много дат для форматирования. Что там так тормозило для меня до сих пор загадка.
Если грамотно собрать ядро зенда — 700Кб 1файлом вместо 8Мб(1600 файлов) + локаль. Да ещё все это под еАкселератором без архивации и все хранить в памяти. Сделать приличный кэш(кэширут он всем чем угодно и вобще все что угодно, за рееедким исключением), то вопрос спорный кто быстрее. )
Не спорю, что скорость приложения в конечном итого зависит от библиотек. НО! почему тогда все пишут ООП код, зная, что он медленнее?! Писали бы все по станике на goto: )))) было бы быстрее. Зачем вобще придумали ZF Cake CI?!
Тут есть ещё несколько показателей, кроме скорости таких как: скорость разработки, время замены модулей (к примеру, поменять способ кэширования) (длительная разработка, доработка — ваши затраты). Поддержка IDE — это удобстро и скорость разработки (отсутствие их ваши затраты). Плюс ещё некоторые моменты, позволяющие комфортно разрабатывать ПО.
На весах скорость работы и скорость разработки, комфорт разработки (цена подукта).
Используем get_included_files получаем все подключаемые библиотеки, затем с помошью уберутилиты от homm собираем файлик. Если используем локаль или Фиглет капчу, то их файлы кладем рядом с собранным ядором. Прирост скорости в 3-10 раз. :)
Допрошу немножко ешё. Интересно узнать каково писать на CI.
А как же нормальные оопшные интерфейсы? )
Вот такая ситуация: вы пишете какой-то проект и пришло время ставить на хост, а хостер изменил политику и отказался от мемкэша, например в пользу XCache. Это для CI критично? Сколько заимет времени замена кэшера? )
Не все так плохо, как вам кажется :) Не обязательно это шара. Могут быть такие проблемы и на внутреннем сервере компании. И не обязательно с кэшем, кэш я привел для примера.
Одна типичных ситуаций из: гендир заключил договор скакой-то компанией и компания гендира будет использовать ОП по контракту (СУБД итд).
Соответственно они отказались от ПО конкурирующей компании. А мы писали под старое ПО, предполагая, что оно вечно и есть везде. (Писали под MySQL а надо будет переделать под Oracle, с СУБД не так все критично из-за ORM ActiveRecord) Да нам оплатят расходы на переделку.., но, что лучше перебить стотыщ строк кода или изменить 5 строк в конфе?! )
в CodeIgniter очень хорошее разграничение между php4 и php5. А сделали они по максимуму т. к. включили и php4 и php5. Всем ведь не угодить, имхо лишнее 100Кб не жалко.
по мне так и для ci дока не супер(слишком мало примеров использования), а в Kohana достаточно понятный код и устройство, хотя да, сыроватый(в плане логики), но достаточно стабильный чтобы использовать.
Ну, далее — это уже знание PHP и от фреймворка, если он не мешает, не зависит. За пару часов новичок в CI, писавший до этого, допустим, на чистом PHP сможет наваять, например, какую-никакую систему комментов.
если дальше знание php то зачем тогда вообще фреймворк?… его задача как раз сократить и упростить необходимый php код, если из фреймворки использовать только контролеры то проще написать небольшой скрипт для этого с нуля. А насчет доки для коханы, она хуже чем от игнитора только тем что в ней нет азов для понимания как работает mvc, а из неточностей один раз наткнулся та то что нет функии в одном хелпере, ее из доки забыли убрать(не смертельно же?).
Его первоочередная задача — не сократить код, а организовать разработчика. Знаете, как сложно скоординировать команду из 10—20 человек, не написав при этом точной документации по собственной наработке?
Документация на Kohana далеко позади самого фреймворка. Я за ней слежу.
никто и не спорит что на словах все просто(как оказывается в последствии так же и на практике). Вот только я писал на ci после зенда(зная общую идеалогию mvc) и пользы от доки кроме как справочника(читать как списка) функций я не получил никакой.
Первоначальная инициализация ZF более-менее лечится слитием используемых файлов в один, отказом от автозагрузки классов. Также, немного лечится PHP 5.3 и выше.
Но до уровня скорости инициализации CI не доходит…
А вот скорость приложения уже зависит только от вас.
Пользуясь случаем, спрошу:
Как хабрапользователи CodeIgniter'а реализуют вывод и валидацию форм, если данные в форму надо при отображении подставлять из базы, а потом уже измененное валидировать?
Не очень очевидно как это делать по-нормальному, пока использую присваивание $this->validation->fieldname = $object_from_bd->fieldname, соотв-но в форме выводится сначала то что было в базе, а потом то, что передано POST'ом. С новым классом (в 1.7) вообще вывод данных в форму делается хелпером… Документацию пока подробно не просмотрел, беглый просмотр результатов не дал. Как это сделать максимально не-коряво?))
CodeIgniter 1.7.0