Un breve recorrido por los aspectos más destacados del Marco Zend

¿Es solo un marco, o este marco representa el orgullo de la comunidad PHP, sus desarrolladores trabajadores, por así decirlo, un ingrediente clave? Con una dispersión de configuraciones ... El tema del amor de nuestro PL, que tiene un buen MVC, por lo que Zend Framework es el mejor framework PHP.

Aquí no encontrará la respuesta a esta pregunta, pero aprenderá sobre ServiceManager y ModuleManager.

Advertencia

1. Este material se basa en lo que estaba buscando en Zend Framework 2, en algunos lugares incluso aparecen menciones de la versión 1. *. No creo que esto se convierta en un problema cuando se compara con otras versiones, ya que se consideran los puntos fundamentales y es poco probable que cambien a nivel mundial.
2. En el razonamiento y las traducciones (así como en el párrafo 1) puede haber errores graves, tanto los míos como las fuentes originales. Todos recibirán enlaces, y su propio trabajo será con una nota [mía] .
3. Está dirigido a aquellos que googlean y, como yo, se confundieron. No habrá despliegue de blogs, explicaciones e interactividad. Pero habrá dos fotos y un gatito.

Contenido

• Términos
• Marco del dispositivo
  
  • Estructura general y relaciones
  • Complementos
• Visualización
  
  • Comunicaciones
  • Diagrama esquemático
• Del autor
  
  • Enlaces utiles
• Bono

Términos

Fuente , un poco [mío] .

• Aplicación - el producto final, sitio;
• Un módulo es un "bloque" funcionalmente completado de una aplicación, cuyo código puede consistir en modelos, vistas, controladores. El módulo amplía la funcionalidad de una aplicación web y solo puede funcionar "dentro" de ella; Los módulos están registrados en application.config.php en la sección de modules
• ModuleManager : un contenedor para manipular módulos;
• Servicio - "mecanismo" en el módulo, para manipulaciones entre modelos, controladores, tipos, etc. Los servicios están registrados en module.config.php en la sección service_manager .
• ServiceManager : un contenedor para manipular servicios.
• ControllerManager : funciona con servicios y fábricas para cargar controladores ( \Zend\ServiceManager\AbstractFactoryInterface o \Zend\ServiceManager\ServiceManager ). muelle
• EventManager : un componente que agrega controladores de eventos (Listener) para uno o más eventos con nombre (Event) y también inicia el procesamiento de estos eventos.
• Un complemento es una clase que extiende la funcionalidad de todos los controladores de alguna manera.

Marco del dispositivo

Estructura general y relaciones

Fuente

Cuando Zend\Mvc\Application , el objeto Zend\ServiceManager\ServiceManager se crea y configura a través de Zend\Mvc\Service\ServiceManagerConfig . ServiceManagerConfig obtiene la configuración de config/application.config.php (o alguna otra configuración de la aplicación que se pasa a la Application cuando se crea). De todos los servicios y fábricas representados en el espacio Zend\Mvc\Service nombres Zend\Mvc\Service , ServiceManagerConfig es responsable de solo tres: SharedEventManager , EventManager y ModuleManager .

Después de eso, la Application recupera el ModuleManager . En este punto, el ModuleManager través del ServiceManager configura los servicios y las fábricas proporcionadas en Zend\Mvc\Service\ServiceListenerFactory . Este enfoque nos permite simplificar la configuración de la aplicación principal y brindar al desarrollador la oportunidad de configurar varias partes del sistema MVC desde los módulos, anulando cualquier configuración predeterminada en los servicios de estos MVC.

ModuleManager , expresado en Zend\Mvc\Service\ModuleManagerFactory . Esta es quizás la fábrica más compleja en la pila MVC. ModuleManager espera que el servicio ApplicationConfig se implemente ( Di ) con las claves module_listener_options y los modules .

Crea una instancia de Zend\ModuleManager\Listener\DefaultListenerAggregate utilizando el module_listener_options extraído. Luego verifica si hay un servicio llamado ServiceListener ; de lo contrario, usa una fábrica llamada Zend\Mvc\Service\ServiceListenerFactory . Se agregarán muchos servicios de escucha al ServiceListener , como los oyentes del getServiceConfig , getControllerConfig , getControllerPluginConfig , getViewHelperConfig .

Luego, ModuleManager recupera el servicio ModuleManager y conecta los oyentes anteriores. Crea una instancia de Zend\ModuleManager\ModuleEvent estableciendo el parámetro "ServiceManager" en el objeto del administrador de servicios. Finalmente, crea una instancia de Zend\ModuleManager\ModuleManager e implementa EventManager y ModuleEvent .

[mío] El caso cuando el código es más claro:

 <?php namespace Zend\Mvc\Service; use Zend\ModuleManager\Listener\DefaultListenerAggregate; use Zend\ModuleManager\Listener\ListenerOptions; use Zend\ModuleManager\ModuleEvent; use Zend\ModuleManager\ModuleManager; use Zend\ServiceManager\FactoryInterface; use Zend\ServiceManager\ServiceLocatorInterface; class ModuleManagerFactory implements FactoryInterface { public function createService(ServiceLocatorInterface $serviceLocator) { if (!$serviceLocator->has('ServiceListener')) { $serviceLocator->setFactory('ServiceListener', 'Zend\Mvc\Service\ServiceListenerFactory'); } $configuration = $serviceLocator->get('ApplicationConfig'); $listenerOptions = new ListenerOptions($configuration['module_listener_options']); $defaultListeners = new DefaultListenerAggregate($listenerOptions); $serviceListener = $serviceLocator->get('ServiceListener'); $serviceListener->addServiceManager( $serviceLocator, 'service_manager', 'Zend\ModuleManager\Feature\ServiceProviderInterface', 'getServiceConfig' ); //        $events = $serviceLocator->get('EventManager'); $events->attach($defaultListeners); $events->attach($serviceListener); $moduleEvent = new ModuleEvent; $moduleEvent->setParam('ServiceManager', $serviceLocator); $moduleManager = new ModuleManager($configuration['modules'], $events); $moduleManager->setEvent($moduleEvent); return $moduleManager; } } 

Complementos

Fuente

La arquitectura del controlador incluye un sistema de complemento que le permite agregar su propio código, que se llamará cuando ocurran ciertos eventos durante la vida útil del controlador. El controlador frontal utiliza un agente de complementos como registro de complementos de usuario; el agente de complementos también proporciona una invocación de métodos de eventos en cada complemento registrado a través del controlador frontal.

Los métodos de eventos se definen en la clase abstracta Zend_Controller_Plugin_Abstract , de la cual todos los complementos de usuario deben heredar

Visualización

[el mío]

• Se lee de arriba a abajo, a menos que las flechas especifiquen lo contrario.
• Las líneas de flecha indican lo que está incluido.
• Las líneas finas sin flechas indican lo que está conectado.
• Las líneas gruesas sin flechas indican qué controles.

Comunicaciones

Esquema

Del autor

El lector atento notó que el artículo comienza con un enlace al Tostador, donde se hace una pregunta sobre las diferencias entre ServiceManager y ModuleManager, y el texto del artículo comienza con ellos. ¿Coincidencia? No lo creo El hecho es que Habr fue el primer lugar desde donde comencé a familiarizarme con los conceptos básicos del marco y la publicación introdujo confusión, donde se recreó un blog a partir de la documentación con comentarios del autor del artículo. Fue la falta de una descripción de ModuleManager lo que me llevó al razonamiento incorrecto (que los módulos están registrados en ServiceManager) y esto llevó a la redacción de este artículo.

Enlaces utiles

No quiero participar en copiar y pegar y hacer crecer 6 partes sobre un tema, así que adjunto una lista de mis marcadores en ZF con notas:

Espero que la breve excursión no haya sido demasiado larga y haya sido útil. Por supuesto, se aceptan ediciones, sugerencias, críticas y otras acciones permitidas por las reglas de Habr y las leyes actuales de la Federación Rusa.

Bonificación que merecemos:

Gatito

(= ^ ･ Ω ･ ^ =)