- PVSM.RU - https://www.pvsm.ru -
Здравствуйте дорогие читатели.
Совсем недавно вышел в свет Zend Framework 2. Однако его изучение у многих усложняет отсутствие русской документации и единого сообщества. Так же во второй ветке этого фреймворка появилось множество нововведений и плюшек, про который обычный PHP программист раньше даже не слышал. Но их можно изучить особо не потея. А вот понять, как работает ZF2 без понимания логики работы его MVC системы достаточно затруднительно. Поэтому решил сделать перевод с официального сайта именно этого раздела.И так приступим.
ZendMvc представляет собой совершено новую реализацию MVC системы для Zend Framework 2. Основное внимание было уделено производительности и гибкости.
Начальной точкой работы MVC является объект ZendMvcApplication (далее Приложение). Основными обязанностями которого являются начальная загрузка ресурсов, направление (роутинг) запросов, получение и отправка контроллеров, соответствующих роутингу.
application_root/
config/
application.config.php
autoload/
global.php
local.php
// etc.
data/
module/
vendor/
public/
.htaccess
index.php
init_autoloader.php
За перенаправление всех пользовательских запросов на сайт отвечает файл public/index.php. Затем получает массив настроек приложения, расположенный в config/application.config.php. После запускает Приложение (Application) вызовом функции run(), которое обрабатывает запросы и в итоге отсылает полученный результат обратно пользователю.
Директория настроек «config» содержит необходимые настройки, используемые в ZendModuleManager для загрузки модулей и объединения конфигураций (настройки подключения к БД, меню, ACL и др.). Более подробно про сказанное немного позже.
Поддиректория «vendor» содержит любые третье- степенные (вспомогательные, third-party) модули библиотеки, необходимые для обеспечения работоспособности Вашего приложения. На пример, там может быть размещен непосредственно сам Zend Framework 2, пользовательские библиотеки, или другие вспомогательные библиотеки различных проектов. Библиотеки и модули, расположенные в данной поддиректории «vendor» не должны изменяться каким либо способом, не должны отличаться от оригинала, над ними нельзя совершать какие либо действия из приложения или сторонних программ.
Директория «module» содержит один или более модулей, обеспечивающих главный функционал Вашего приложения.
Содержимое модуля может быть абсолютно любым: PHP код, функциональные MVC структуры, коды библиотек, скрипты видов, публичные (public) ресурсы, такие как картинки, каскадные таблицы стилей CSS, JavaScript код и др. Единственное требование, и то оно не является обязательным — модуль должен выступать пространством имен (namespace) и содержать класс Module.php в пределах этого пространства имен. Этот класс необходим для нормальной работы ZendModuleManager и ряда других задач.
Рекомендуется придерживаться следующей структуры при создании модуля:
module_root<named-after-module-namespace>/
Module.php
autoload_classmap.php
autoload_function.php
autoload_register.php
config/
module.config.php
public/
images/
css/
js/
src/
<module_namespace>/
<code files>
test/
phpunit.xml
bootstrap.php
<module_namespace>/
<test code files>
view/
<dir-named-after-module-namespace>/
<dir-named-after-a-controller>/
<.phtml files>
В силу того, что модуль выступает пространством имен, корневой каталог модуля и есть это пространство имен. Пространство имен может включать вендорный префикс принадлежности. Для наглядности, модуль обеспечивающий базовую функциональность для пользователя «User», разработанный командой Zend может называться (желательно, но не обязательно) «ZendUser» — так же это является названием корневой папки модуля и пространства имен одновременно. Файл Module.php, расположенный сразу в корневой папке модуля будет уже находиться в пространстве имен данного модуля. Смотрим пример ниже:
namespace ZendUser;
class Module
{
}
Если определен метод init(), то он будет вызван слушателем ZendModuleManager’а, после загрузки класса, и передачи экземпляра менеджера по умолчанию. Такой подход позволяет создавать особых слушателей событий. НО! Будьте осторожны с методом init()! Он вызывается для каждого модуля на каждый запрос и должен использоваться исключительно для «легковесных» задач, таких как регистрация слушателей.
Тоже касается и метода onBootstrap(), который принимает экземпляр объекта MvcEvent и вызывается для каждого модуля при каждом запросе.
Три файла autoload_*.php необязательны, но желательны. Они обеспечивают следующее:
Эти три файлы обеспечивают загрузку по умолчанию классов, находящихся в модуле без использования ZendModuleManager. Например для использования модуля вне ZF2.
Директория «config» должна содержать различные специфические настройки модуля. Эти настройки могут быть в любом формате, который поддерживает ZendConfig. Желательно использовать для главного файла конфигурации имя «module.format». Например, для файла конфигурации в формате PHP имя главного конфигурационного файла должно быть таким: module.config.php. Как правило Вам придется создавать файлы настройки для маршрутизации и инъекций зависимости.
Директория «src» должна быть совместима с форматом PSR-0 и содержать основной код модуля. Как минимум, в ней должен быть подкаталог, названый так же, как и пространство имен модуля (корневая папка модуля). Однако может содержать код и с разными пространствами имен, если это необходимо.
Директория «test» должна содержать ваши unit-тесты. Как правило они пишутся с использованием PHPUnit и содержат файлы, связанные с его настройкой.
Директория «public» используется для общедоступных ресурсов. Это могут быть картинки, CSS, JavaScript и др. Полностью на усмотрение разработчика.
Директория «view» содержит скрипты видов, связанные с различными контроллерами.
Приложение имеет шесть основных зависимостей:
Вышеперечисленное может быть реализовано при инициализации:
use ZendEventManagerEventManager;
use ZendHttpPhpEnvironment;
use ZendModuleManagerModuleManager;
use ZendMvcApplication;
use ZendServiceManagerServiceManager;
$config = include 'config/application.config.php';
$serviceManager = new ServiceManager();
$serviceManager->setService('EventManager', new EventManager());
$serviceManager->setService('ModuleManager', new ModuleManager());
$serviceManager->setService('Request', new PhpEnvironmentRequest());
$serviceManager->setService('Response', new PhpEnvironmentResponse());
$application = new Application($config, $serviceManager);
После выполнения всего, что было описано выше, у Вас есть выбор из двух действий.
Первое: Вы можете начать загрузку приложения (bootstrap). В реализации по умолчанию это выглядит так:
Если Вам нет необходимости выполнять эти действия, то можете сами задать альтернативы, расширяя класс Application и/или просто написав необходимый код.
Второе: Просто запустить приложение, вызвав метод run(). Этот метод сделает следующее:
Если возникнут ошибки в процессе выполнения событий «route» или «dispatch», то сработает событие «dispatch.error».
Для начала кажется, что нужно запомнить сильно много информации, что бы запустить приложение, поэтому мы не приводим все доступные сервисы. Для начала будет вполне достаточно использование ServiceManager.
use ZendLoaderAutoloaderFactory;
use ZendMvcServiceServiceManagerConfig;
use ZendServiceManagerServiceManager;
// setup autoloader
AutoloaderFactory::factory();
// get application stack configuration
$configuration = include 'config/application.config.php';
// setup service manager
$serviceManager = new ServiceManager(new ServiceManagerConfig());
$serviceManager->setService('ApplicationConfig', $configuration);
// load modules -- which will provide services, configuration, and more
$serviceManager->get('ModuleManager')->loadModules();
// bootstrap and run application
$application = $serviceManager->get('Application');
$application->bootstrap();
$response = $application->run();
$response->send();
Очень быстро Вы заметите, что у Вас в руках очень гибкая система с большим количеством различных настроек. Используя ServiceManager Вы получаете контроль над остальными доступными сервисами, их инициализацией и внедрением зависимостей. Используя EventManager получаете возможность перехватывать любые события, возникающие в приложении («bootstrap», «route», «dispatch», «dispatch.error», «render», «finish»), в любое время и в любом месте, что позволяет создавать свои процессы в приложении при необходимости.
Описанный ранее подход работает. Но возникает вопрос, откуда взялись настройки приложения? Логично предположить, что настройки берутся непосредственно из самого модуля. И как тогда получить эти настройки в свое распоряжение?
Ответом на эти вопросы является ZendModuleManagerModuleManager. Сначала, этот компонент позволяет Вам указать, где находятся модули. Затем он находит каждый модуль и инициализирует его. Классы Module связываются различными слушателями в ModuleManager для обеспечения конфигурации, настроек, слушателей и многого другого. Если Вам кажется это сложным, то это ошибочное предположение.
Сначала займемся настройкой Module Manager. Просто сообщите Module Manager какие модули необходимо загружать, а при необходимости можно еще указать и настройки для слушателей модулей.
Теперь давайте вспомним про файл application.config.php, описанный ранее. Зададим настройки следующим образом:
<?php
// config/application.config.php
return array(
'modules' => array(
/* ... */
),
'module_listener_options' => array(
'module_paths' => array(
'./module',
'./vendor',
),
),
);
Что бы добавить модули, необходимо просто добавить элементы в массив модулей.
Каждый класс модуля Module должен определять метод getConfig(). Он должен возвращать массив или объект Traversable, такой как ZendConfigConfig.Рассмотрим на примере:
namespace ZendUser;
class Module
{
public function getConfig()
{
return include __DIR__ . '/config/module.config.php'
}
}
Так же существует еще целый ряд методов, которые можно определить для выполнения таких задач, как автозагрузка настроек, предоставление сервисов из ServiceManager, слушателей событий загрузки и др. Более подробно в документации по ModuleManager.
Слой ZF2 MVC является невероятно гибким, дает возможность легко создавать модули и рабочие процессы в Вашем приложении с помощью ServiceManager и EventManager. ModuleManager представляет собой легкий и простой подход к вопросу о модульной архитектуре, которая поощряет чистое разделение интересов и повторное использование кода.
Более подробно можно ознакомиться с документацией на сайте Украинского сообщества ZF2 [1].
Оригинал статьи [2]
Автор: struggleendlessly
Источник [3]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/mvc/25406
Ссылки в тексте:
[1] Украинского сообщества ZF2: http://zf2.com.ua/
[2] Оригинал статьи: http://framework.zend.com/manual/2.0/en/modules/zend.mvc.intro.html
[3] Источник: http://habrahabr.ru/post/166657/
Нажмите здесь для печати.