Instancia de ayuda de Magento 2

Cuando creo que obtuve mi cabeza envuelta alrededor del sistema DI de Magento 2, algo surge y lo desenvuelve.
Veo en el código central diferentes formas de acceder a un ayudante.
Por ejemplo, Magento\Catalog\Controller\Category::_initCategoryahí está esto:

if (!$this->_objectManager->get('Magento\Catalog\Helper\Category')->canShow($category)) {
    return false;
}

Pero en Magento\Catalog\Block\Category\Viewel ayudante se inyecta en el constructor

public function __construct(
    \Magento\Framework\View\Element\Template\Context $context,
    \Magento\Catalog\Model\Layer\Category $catalogLayer,
    \Magento\Framework\Registry $registry,
    \Magento\Catalog\Helper\Category $categoryHelper,
    array $data = array()
) {
    $this->_categoryHelper = $categoryHelper;
    $this->_catalogLayer = $catalogLayer;
    $this->_coreRegistry = $registry;
    parent::__construct($context, $data);
}

Esto me llevó a pensar que se debería acceder a los ayudantes de manera diferente en los controladores y bloques (y modelos), pero luego encontré un controlador donde se inyecta un ayudante en el constructor Magento\Catalog\Controller\Adminhtml\Product\Action\Attribute.

Por favor, despeja la niebla para mí.
¿Cuándo debo usar DI y cuándo debo usar objectManager? ¿y por qué?
He leído esta pregunta: Instanciando ayudantes en Magento 2 . Esta es solo una pregunta de seguimiento sobre eso.

Preferiría DI siempre que sea posible, ya que usar el administrador de objetos ya es una violación de la ley de demeter. Cuando se usa el administrador de objetos, estas dependencias se ocultan en la lógica del método.

No sé mucho sobre la implementación de Magento, pero parece que ObjectManageres un Localizador de servicios .

En general, usar un Localizador de servicios para acceder a dependencias en un objeto es bastante malo, consulte este artículo .

Definir explícitamente sus dependencias a través de un constructor es un enfoque mucho mejor. Ayuda en pruebas unitarias y problemas de tiempo de ejecución con servicios no definidos.

Inyectar el Administrador de objetos en una clase es básicamente inyectar un Registro en su clase que tiene acceso a todos sus servicios de aplicaciones, lo que obviamente no es correcto.

Utilizo ZF2 bastante y generalmente defino clases pequeñas de fábrica para servicios, controladores y cualquier clase que requiera dependencias. Estas clases de fábrica tienen acceso al Localizador de servicios y toman todos los servicios de los que depende el objeto, y los inyecta a través del constructor. El uso de un Localizador de servicios en una clase de Fábrica está bien, ya que se trata principalmente de código desechable, algo como esto, por ejemplo.

Estas fábricas aún son fáciles de probar .

OMI, use la inyección del constructor siempre que sea posible. Una vez más, no sé demasiado sobre la implementación de Magento y si tiene el concepto de Fábricas, a simple vista parece que las admite, pero definir explícitamente sus clases y usar un Localizador de servicios para construirlas en las clases de Fábrica es Un enfoque mucho más limpio.

Esto es de alguien que tiene una exposición limitada a los patrones mencionados anteriormente, por lo que también me gustaría escuchar los pensamientos / experiencias de otros sobre el asunto.

Más lectura

• http://ralphschindler.com/2012/10/10/di-dic-service-locator-redux

Otra forma de usar helper (en plantillas) es:

$this->helper('[Vendor]\[Module]\Helper\[Helper Name]')->getMethodName();

Espero que sea útil si aún no lo sabías.

Aunque es una pregunta antigua, no estoy seguro de si Marius obtuvo su respuesta. Creo que Marius puede responderlo mejor. Me gustaría responder en breve. ¿Por qué Magento 2 sugiere usar DI en lugar de ayuda?

• Hacer posible el aislamiento en las pruebas unitarias / fácil
• Definición explícita de dependencias de una clase
• Facilitar un buen diseño (principio de responsabilidad única (SRP) por ejemplo)
• El uso de DI en su módulo reduce el riesgo de errores de incompatibilidad cuando Magento cambia la implementación subyacente de esas interfaces. Este es un concepto importante para los desarrolladores de extensiones.

¿Por qué el núcleo M2 podría no usar DI en algunos casos?

• Número decreciente de clases
• No crear interfaces innecesarias
• Sin riesgo de errores de incompatibilidad

Aunque el módulo de catálogo Core se ha usado como ayudante, se ha usado DI ampliamente. En mi investigación, descubrí que Magento 2 usaba pocas funciones en los archivos auxiliares del Catálogo principal que no son adecuados para los contratos de servicio.

Si debe usar explícitamente una clase definida por Magento (como \ Magento \ Catalog \ Model \ Product), haga explícita la dependencia implícita dependiendo de la implementación concreta en lugar de la interfaz del contrato de servicio.

Sin lugar a dudas, el desarrollador de extensiones debe usar DI en lugar de Magento1 como Helper. Cuando se implementa de acuerdo con las pautas de Magento 2, las consecuencias son limitadas. Cuando se rompen las recomendaciones, ocurren problemas.