Patrones de diseño de Magento

Magento, en mi humilde opinión, representa un sistema PHP que se basa en principios de encoding bien pensados: los patrones de diseño reutilizables son uno de ellos. En términos de un ejemplo de un sistema PHP, creo que se puede considerar como de vanguardia y, por lo tanto, vale la pena considerarlo desde un punto de vista arquitectónico.

Según tengo entendido, hay muchos patrones de diseño disponibles para el desarrollador de OOP. Ver que esos patrones se usen en un sistema de código abierto como Magento le permite a un desarrollador ver ejemplos de tales patrones en uso real e in situ, en lugar de ejemplos que a veces pueden ser bastante académicos e incluso un poco engañosos.

Como tal, me pregunto qué patrones, además de los que he enumerado a continuación, los progtwigdores de Magento han utilizado al desarrollar para Magento.

Como nota, entiendo que algunos de estos patrones están en su lugar como consecuencia de haberse construido sobre Zend Framework, siendo MVC / Front Controller un par de ellos,

Los más obvios son:

Fábrica:

$product = Mage::getModel('catalog/product'); 

Semifallo:

 $category = Mage::getSingleton('catalog/session'); 

Registro:

 $currentCategory = Mage::registry('current_category'); 

Prototipo:

 Mage:getModel('catalog/product')->getTypeInstance(); 

Par observador-evento:

 # PHP Mage::dispatchEvent('event_name', array('key'=>$value)); # config.xml       Class_Name methodName       

Conjunto de objetos:

 $id = Mage::objects()->save($object); $object = Mage::objects($id); 

Iterador:

 Mage::getModel('catalog/product')->getCollection(); 

Patrones de diseño encontrados en Magento en detalles

  1. Modelo de controlador de vista modelo

Model View Controller, MVC para abreviar, es un patrón de diseño donde se separan la lógica de negocios, presentación y acoplamiento. Magento utiliza en gran medida XML como plantilla de lógica y HTML mezclado con archivos PHP para sus vistas. Los modelos están respaldados por el ORM de Varien. La mayoría de la lógica empresarial ocurre en los modelos, mientras que los controladores asignan los datos del modelo a las vistas.

Debido a que Magento sus puntos de vista son “gordos”, a menudo contienen mucha lógica, no es raro que las vistas tengan una clase de PHP adicional (el sistema de Bloques) que ayudará con la representación.

  1. Patrón de controlador frontal

El patrón del controlador frontal se asegura de que haya un solo punto de entrada. Todas las solicitudes se investigan, se enrutan al controlador designado y luego se procesan de acuerdo con la especificación. El controlador frontal es responsable de inicializar el entorno y las solicitudes de enrutamiento a los controladores designados.

Magento solo tiene un punto de entrada (index.php) que inicializará el entorno de la aplicación (Mage :: app ()) y enrutará la solicitud al controlador correcto.

  1. Patrón de fábrica

Tal como lo implica el nombre, el patrón de fábrica es responsable de factorizar (crear instancias) las clases. Se usa ampliamente a través de la base de código de Magento y aprovecha el sistema de carga automática en Magento. Al definir un alias en un módulo, config.xml le está permitiendo a la fábrica saber dónde puede encontrar clases.

Hay varios métodos de ayuda de fábrica en la clase de núcleo de Mage y uno de ellos es getModel (). Acepta un alias para una clase y luego devolverá una instancia de la misma. En lugar de tener llamadas de inclusión dispersas a través de la base de código, el patrón de fábrica instanciará las clases de una manera uniforme.

  1. Patrón Singleton

Otra forma de recuperar una instancia de una clase es llamar a Mage :: getSingleton (). Acepta un alias de clase y antes de devolver una instancia, comprueba el registro interno si esta clase ya se ha instanciado antes; esto da como resultado una instancia compartida. Un ejemplo de dónde esto es obligatorio, es el almacenamiento de la sesión que debe compartirse a través de la base de código en lugar de crearlo de nuevo cada vez.

  1. Patrón de registro

Todos los singletons se almacenan en el registro interno: un contenedor con ámbito global para almacenar datos. No es solo para uso interno. Los métodos Mage :: register ($ key, $ value), :: registry ($ key) y :: unregister ($ key) se pueden usar respectivamente para almacenar, recuperar y eliminar datos del registro. El registro se usa a menudo para transferir datos entre ámbitos cuando no se pueden transmitir, de lo contrario.

  1. Patrón prototipo

Donde el patrón de fábrica (n. ° 3 en nuestra lista) se detiene, es donde continúa el patrón del prototipo. Define que las instancias de clases pueden recuperar una instancia específica de otra clase en función de su clase principal (el prototipo). Un ejemplo notable es la clase Mage_Catalog_Model_Product que tiene un método getTypeInstance para recuperar el Mage_Catalog_Model_Product_Type específico con un subconjunto específico de métodos y propiedades que no se aplica a todos los productos.

Por ejemplo, Mage_Downloadable_Model_Product_Type finalmente extiende el Mage_Catalog_Model_Product_Type. Si está iterando sobre un pedido y desea llamar a un método específico de un producto descargable, primero deberá factorizarlo con el método getTypeInstance del producto original.

  1. Patrón de grupo de objetos

El patrón de grupo de objetos es simplemente un cuadro con objetos para que no tengan que asignarse y destruirse una y otra vez. No se usa mucho en Magento aparte de las tareas pesadas, donde los recursos pueden limitarse pronto, como la importación de productos. Se puede acceder al grupo de objetos (administrado por Varien_Object_Cache) con Mage :: objects ().

  1. Patrón de iterador

El patrón de iterador define que hay una forma compartida de iterar sobre un contenedor con objetos. En Magento, esto es manejado por Varien_Data_Collection que a su vez usa varias clases de PHP horneadas (como ArrayIterator) para tener una interfaz más OO para las matrices. Esto garantiza que las colecciones de modelos siempre tendrán una API común para iterar sin depender de los modelos reales.

  1. Patrón de carga diferida

La carga diferida garantiza que los datos de carga se retrasen hasta el momento en que realmente se necesiten. Esto da como resultado que se usen menos recursos. Uno de los comportamientos de carga flojos de Magento es el de las colecciones. Si tuviera que recuperar una colección de productos con Mage :: getModel (‘catalog / product’) -> getCollection (), la base de datos solo se tocará cuando realmente acceda a la colección, por ejemplo, iterando sobre ella o recuperando el recuento de modelos encontrados.

  1. Patrón de localizador de servicio

El patrón del localizador de servicios abstrae la recuperación de un determinado servicio. Esto permite cambiar el servicio sin romper nada (ya que se adhiere a su base abstracta), sino que también busca el servicio como se considera adecuado para su propósito.

Ryan ejemplifica esto con las conexiones de bases de datos. Otro ejemplo es el de Magento, su mecanismo de caché, donde Mage :: getCache () es un proxy de localización de servicios para el almacenamiento en caché proporcionado por Zend u otros proveedores.

  1. Patrón de módulo

Cualquiera que esté familiarizado con el desarrollo de Magento ha tropezado con el patrón del módulo. Básicamente define que los diferentes dominios se agrupan en módulos separados que funcionan independientemente el uno del otro y se pueden conectar al sistema principal según se considere apropiado. En una situación ideal, una implementación del patrón del módulo aseguraría que cada elemento se pueda eliminar o intercambiar. Uno de los protagonistas del patrón de módulos en PHP es el administrador de paquetes Composer.

Aunque Magento depende en gran medida de una architecture modular, no es modular hasta el hueso. Cierta funcionalidad está fuertemente ligada al núcleo y no se puede cambiar fácilmente. También existe el uso intensivo de la clase central súper global de Mage, que introduce todo tipo de dependencias de todo el sistema que no son fácilmente supervisadas.

  1. Patrón de observador

Magento su architecture impulsada por eventos es el resultado de una implementación del patrón de observadores. Al definir observadores (u oyentes), se puede conectar un código adicional que se invocará a medida que se dispara el evento observado. Magento usa su almacenamiento de datos XML para definir observadores. Si se dispara un evento con Mage :: dispatchEvent ($ eventName, $ data), se consultará el almacenamiento de datos y se dispararán los observadores correspondientes para $ event.

Un poco mas:

Evento / oyentes :

 Mage::dispatchEvent('model_load_before', $params); 

Y, por supuesto, MVC , con Vistas representadas por una combinación de XML, PHP Classes y plantillas de PHTML.

No se olvide de la carga diferida, lo que significa que el acceso a la base de datos solo se produce cuando es estrictamente necesario. Por ejemplo:

 $collection_of_products = Mage::getModel('catalog/product') ->getCollection(); $collection_of_products->addFieldToFilter('sku','n2610'); 

La consulta de la base de datos no se realizará hasta que intente acceder a un elemento en la Colección.

Creo que la relación entre Mage_Checkout_Model_Cart y Mage_Sales_Model_Quote es un patrón de diseño de Bridge . Según la definición de wikipedia Bridge, pretende “desacoplar una abstracción de su implementación para que ambas puedan variar de forma independiente”. Por lo tanto, Cart parece ser la abstracción y Quote parece ser la implementación.

Localizador de servicio

 Allows overrides or renamed physical resources (eg Classes, DB tables, etc) 

Mage::getModel('catalog/product') y $installer->getTable('customer/address_entity')

Los siguientes son patrones de diseño: 1. Model View Control.

  1. Semifallo

  2. Fábrica

  3. Registro

  4. Controlador frontal

  5. Iterador.

  6. Carga lenta.

  7. Observadores (eventos)

En general, desde mi punto de vista, Magento utiliza su propia implementación única de la mayoría de los patrones, por lo que no debería compararse tanto.

Por ejemplo, en el pasado he visto el patrón creacional Factory como una clase, que maneja las clases del grupo de instanciación. En Magento, el archivo config xml fusionado almacena todas las rutas a modelos, bloques y ayudantes, en orden en el proceso de desarrollo, los desarrolladores deben especificar solo el identificador único para la barra diagonal y el nombre real de la clase. Los patrones de Singleton y del Registro también son diferentes de lo esperado.