Inyección de dependencias en un Magento 2 CRUD / Modelo abstracto

¿Es posible inyectar una dependencia en un modelo Magento 2 CRUD?

Eso es - Magento 2 tiene una clase base abstracta modelo: Magento\Framework\Model\AbstractModel. Si desea crear un objeto modelo simple Crear, Leer, Actualizar, Eliminar, amplíe esta clase con su propia clase.

class Foo extends Magento\Framework\Model\AbstractModel
{
}

¿Es posible tener dependencias inyectadas en el __constructmétodo de su modelo ? Cuando lo intento, termino obteniendo el siguiente error.

Error fatal: no se puede crear una instancia de la clase abstracta Magento \ Framework \ Model \ ResourceModel \ AbstractResource

El culpable parece ser el AbstractModel's __constructmétodo.

public function __construct(
    \Magento\Framework\Model\Context $context,
    \Magento\Framework\Registry $registry,
    \Magento\Framework\Model\ResourceModel\AbstractResource $resource = null,
    \Magento\Framework\Data\Collection\AbstractDb $resourceCollection = null,
    array $data = []
) {

Hay dos sugerencias de tipo en este constructor ( Magento\Framework\Model\ResourceModel\AbstractResource, Magento\Framework\Data\Collection\AbstractDb) que no son interfaces de administrador de objetos de Magento. Son clases abstractas. Cuando extiendo esta clase e intento agregar mi dependencia inyectada

class Foo extends Magento\Framework\Model\AbstractModel
{
    public function __construct(
        \Magento\Framework\Model\Context $context,
        \Magento\Framework\Registry $registry,
        \Magento\Framework\Model\ResourceModel\AbstractResource $resource = null,
        \Magento\Framework\Data\Collection\AbstractDb $resourceCollection = null,
        array $data = [],
        \Package\Module\Model\Mine $mine,

    ) {
        //...
        parent::__construct($context, $registry, $resource, $resourceCollection, $data);

    }
}

Magento rescata cuando el administrador de objetos intenta instanciar las clases abstractas.

Puedo "arreglar" esto moviendo mi dependencia de objeto frente a las clases abstractas

    public function __construct(
        \Magento\Framework\Model\Context $context,
        \Magento\Framework\Registry $registry,

        \Package\Module\Model\Mine $mine,

        \Magento\Framework\Model\ResourceModel\AbstractResource $resource = null,
        \Magento\Framework\Data\Collection\AbstractDb $resourceCollection = null,
        array $data = [],
    ) {  

Sin embargo, esto cambió el orden del argumento. En una clase que estaba completamente administrada por objetos, esto no sería un problema. Sin embargo, el hecho de que existan estas sugerencias de tipo de clase abstracta implica que hay partes del sistema Magento que crearán manualmente (es decir, no a través del administrador de objetos o DI) objetos CRUD y pasarán objetos que se ajusten a las sugerencias de tipo en ese orden específico .

¿Es esto seguro? es decir, ¿estas clases abstractas en el constructor de un modelo abstracto son solo código heredado y no se usan? ¿O algunas partes del sistema seguirán usándolas, lo que significa que no es posible inyectar dependencias en un modelo CRUD?

En primer lugar, el constructor es una API privada de clase. La función de constructor tiene un significado especial y no requiere tener la misma lista / orden de argumentos que en la clase padre.

¿Es posible inyectar una dependencia en un modelo Magento 2 CRUD?

Sí, por supuesto.

¿Es esto seguro?

Sí, pero Magento Object Manager supone que todos los parámetros opcionales se colocan al final de la lista y los parámetros requeridos después de opcional no se resolverán.

Los argumentos $ resource, $ resourceCollection son heredados pero aún se usan ampliamente en las clases Model. La mayoría del modelo usa código como este para inicializar recursos y clases de colección.

protected function _construct() { 
    $this->_init('Magento\AdminNotification\Model\Resource Model\Inbox'); 
}

Es por eso que estos parámetros son opcionales. Pero, por ejemplo, en la prueba unitaria, pasamos simulacros de recurso o colección en el constructor para permitir la realización de reemplazo.

Esto parece ser seguro. Al menos, Magento está haciendo esto en varios lugares. Vea los métodos __construct en la siguiente lista (no exclusiva) de clases para ver ejemplos

• \ Magento \ Theme \ Model \ Theme \ File
• \ Magento \ Theme \ Model \ Design
• \ Magento \ Sales \ Model \ Order \ Creditmemo

Lamentablemente, no puedo responder la otra parte de tu pregunta.

1. ¿Cómo usas tu modelo?
2. En su caso $minees un parámetro obligatorio , while $resource, $resourceCollectiony $datason opcionales . Los parámetros opcionales siempre deben ir al final, de lo contrario es imposible trabajar con ellos como con los opcionales. Por lo tanto, me parece bien que debe especificar $mineantes que cualquier parámetro opcional.