Я даже читал на многих сайтах, что для повышения производительности приложений Zend Framework не использовать Zend_Application в bootstrap, но не удалось найти сайт, на котором это продемонстрировано.
Вы, ребята, знаете о месте, где описан этот метод, и могли бы предоставить мне некоторые образцы кода?
благодаря
Я просто бросил это вместе:
https://gist.github.com/2822456
Воспроизведено ниже для завершения. Не проверено, просто некоторые идеи о том, как я думаю, что это вообще (!) Может сработать. Теперь, когда я немного прошел через него, я больше ценю Zend_Application, его классы начальной загрузки и его настраиваемые / повторно используемые ресурсы приложений. 😉
// Do your PHP settings like timezone, error reporting // .. // Define path to application directory defined('APPLICATION_PATH') || define('APPLICATION_PATH', realpath(dirname(__FILE__) . '/_zf/application')); // Define application environment defined('APPLICATION_ENV') || define('APPLICATION_ENV', (getenv('APPLICATION_ENV') ? getenv('APPLICATION_ENV') : 'production')); // Ensure library/ is on include_path set_include_path(implode(PATH_SEPARATOR, array( realpath(APPLICATION_PATH . '/../library'), get_include_path(), ))); // Get autoloading in place require_once 'Zend/Loader/Autoloader.php'; $autoloader = Zend_Loader_Autoloader::getInstance(); // Any additional configs to autoloader, like custom autoloaders // Read config $config = new Zend_Config_Ini(APPLICATION_PATH . '/configs/application.ini', APPLICATION_ENV); // bootstrap resources manually: // * create db adapter // * create resource autoloaders with the mappings you need // * etc // Get the singleton front controller $front = Zend_Controller_Front::getInstance(); // Set controller directory $front->setControllerDirectory(APPLICATION_PATH . '/controllers'); // Or set module directory $front->setModuleDirectory(APPLICATION_PATH . '/modules'); // Other front config, like throw exceptions, etc. // ... // // Create a router $router = new Zend_Controller_Router_Rewrite(); // Add routes to the router $router->addRoute('myRoute', new Zend_Controller_Router_Route(array( // your routing params ))); // More routes... // Alternatively, the routes can all be in an xml or ini file and you can add // them all at once. // Tell front to use our configured router $front->setRouter($router); // Add an plugins to your $front $front->registerPlugin(new My_Plugin()); // other plugins... // Dispatch the request $front->dispatch(); Возможно, есть и другие средства View / ViewRenderer. Но, как отмечалось в других местах, ViewRenderer несет нетривиальный удар производительности. Если проблема связана с производительностью, вам нужно отключить ViewRenderer и заставить ваши контроллеры действий вызывать собственный рендеринг с помощью $this->view->render('my/view-script.phtml')
Когда вы вызываете $front->dispatch() , объекты $request и $response будут созданы автоматически. Если вы хотите сделать что-то конкретное для них при загрузке – например, установить кодировку в заголовке Content-Type ответа, тогда вы можете сами создать свой объект запроса / ответа, сделать то, что вы хотите, а затем прикрепить его к передней панели с $front->setResponse($response); То же самое для объекта запроса.
Хотя я вижу, что в моем примере используются Zend_Loader_Autoloader и Zend_config_Ini которые примечания Padraic понесут удары производительности. Следующим шагом будет обращение к ним с помощью массивов для конфигурации, удаление вызовов require_once из фреймворка, регистрация другого автозагрузчика и т. Д., Упражнение, оставленное читателю … 😉
Привет, я не согласен с тем, что не использовал Zend_Application в bootstrap, и нет, я еще не видел конкретного примера этой техники.
Лично я не вижу преимущества в том, что вы не используете Zend_app для самонастройки вашего приложения, предполагая, что: a) вы делаете «путь Zend» и b) ваш проект либо достаточно велик, либо просто требует использования рамки Zend (или любой из них дело).
В то время как Zend_App отлично подходит для создания последовательных комплексных бутстрапов в стандартизованной структуре, он не приходит без значительного повышения производительности для базовой производительности. Более прямой бутстрап (типичный для ZF до тех пор, пока Zend_App не прибыл) намного быстрее и может быть также выполнен без файлов конфигурации.
Взято из ссылки Pádraic Brady.
Для меня это не имеет смысла, он в основном просто сказал, что Zend_App отлично подходит для сложных бутстрапов, но добавляет удар производительности. Но разве это не предпосылка для ЛЮБОГО элемента структуры / рамки? Я знаю, что Падрейк – очень умный парень, и я уверен, что он рассуждает, но я тоже хотел бы увидеть примеры / доказательства этого предложения.
Возможно, отвечая на ваш вопрос, вы можете сравнить базовое приложение с использованием последней основы Zend, а затем использовать фреймворк Zend с <1.10 с использованием старого метода не Zend_App, но я бы сказал, хотя, очевидно, не идеальный Zend_App явно ускоряет получение большинства приложений и работает, так ли это стоит «хита производительности», я догадываюсь до разработчика (ов).
Вот ссылка, которая несколько вникает в то, что вам может быть, но ссылается на модульный подход (тем не менее интересный, тем не менее):