Magento 2: diferencia entre modelos y modelos de datos

Soy consciente de que Magento 2 introdujo modelos de datos como parte de la arquitectura del contrato de servicio. Los modelos de datos generalmente implementan interfaces definidas en Api / Data / de un módulo.

Pero, Magento parece haber conservado los viejos modelos también.

Tomemos un ejemplo de módulo-cliente.

• Interfaz del modelo de datos definida en Api / Data / CustomerInterface.php
• La interfaz anterior se implementa en Model / Data / Customer.php
• El modelo de datos tiene todas las funciones getter y setter para las variables del cliente, como cabría esperar.
• Además de lo anterior, también hay un Model / Customer.php. Esto también tiene la función getter y setter. Esto se parece más a un modelo de Magento 1 que se conecta al ResourceModel (Model / ResourceModel / Customer.php)
• En Model / ResourceModel / CustomerRepository.php, varias funciones recopilan datos del modelo Magnento 1, los transfieren al modelo de datos y luego devuelven el modelo de datos.

¿Por qué se necesita el viejo modelo? ¿Por qué el modelo de datos no puede conectarse directamente con ResourceModel?

Mi explicacion:

Es muy difícil entender la diferencia entre un modelo y un modelo de datos. Si tengo que decir en pocas palabras, podría decir que un modelo representa el motor y un modelo de datos representa su información .

En su ejemplo, con la entidad del cliente, puede ver, por ejemplo, cómo se mantienen el método authenticateo validatePasswordel modelo del cliente, ya que son parte del motor y no van a manejar la información directamente. Por otro lado, métodos como getExtensionAttributes, dado que el manejo de piezas de información se mantienen en el modelo de datos.

Creo que este es solo un mejor manejo del proyecto, al igual que la división entre modelos y modelos de recursos, podría preguntar por qué también los necesita.

Por qué los necesitas:

Si desea exponer la información del cliente (por ejemplo) utilizando API, necesitará una interfaz ( \Magento\Customer\Api\Data\CustomerInterface) con captadores que definan todos los atributos de su entidad, y si tiene algún otro método captador que no represente una información que desea exponer (por ejemplo: getRandomConfirmationKey), ¡tienes un problema!

Esta es la razón por la cual, en mi ejemplo, getRandomConfirmationKeyes parte del modelo ( \Magento\Customer\Model\Customer), mientras que getFirstnamees parte del modelo de datos.

Una regla rápida podría ser:

• Si su método representa una columna de tabla, un atributo o una información de entidad de cualquier tipo, entonces debe ir al modelo de datos .
• Si su método es una "acción" en la información, maneja la información o la declara en webapi.xml , entonces debería ser un método modelo .

ENVIAR:

En pocas palabras: considere un modelo de datos casi como un DTO.

Agregando a la respuesta @ Phoenix128_RiccardoT, vale la pena notar que los repositorios (es decir, MagentoCms\Api\BlockRepositoryo Magento\Customer\Api\CustomerRepositoryInterface) también esperan que proporcione un modelo de datos y no uno regular. Los modelos de datos son una capa de abstracción sobre los modelos estándar que expone solo los datos proporcionados por la entidad. Todas las "acciones" sobre estos datos se mueven a otra parte.

Se parece un poco a la idea de entidad en Symfony2 y Symfony3 donde las entidades contienen solo datos y cualquier manipulación de datos está teniendo lugar en el administrador de entidades. En Magento2, este papel, creo, se le dio a los repositorios.

Los modelos antiguos todavía están con nosotros porque se desarrolló magento2. Evidentemente, no comenzaron desde index.php en blanco, sino que reutilizaron parte del código de M1. Cuando se echa un vistazo a los métodos normalizados ( load(), save()y delete()) todos se marcan como deprecated. Esto se debe a que el trabajo se mueve a los repositorios (dado que en algunos casos todo el repositorio ahora llama a este save()método de modelo regular , pero el camino me parece claro).

Los modelos encapsulan la lógica comercial independiente del almacenamiento, no conocen los motores o las instancias de la base de datos, en Magento 2, los modelos de datos son objetos de transferencia de datos (DTO), implementación de las interfaces específicas de DTO (modelo de datos) para los modelos Magento CRUD (el modelo ) determina qué métodos de clase están disponibles a través de Magento WebAPI.

Model/Data/Customer.phpdetermina qué métodos están disponibles para la API, mientras que Model/Customer.phptiene una implementación de tipo Magento 1 heredada de getters y setters personalizados disponibles para operaciones que no son API.

Model/ResourceModel/CustomerRepository.php es parte de una nueva característica introducida en Magento 2 - Contratos de servicio, funciona con la combinación de DTO (Modelos de datos).

Como sabemos que Magento ORM consiste en modelos, modelos de recursos y colecciones y depende de la base de datos, el propósito de un contrato de servicio es ocultar la lógica de almacenamiento para que un cliente conectado al repositorio (contrato de servicio) no se preocupe por el almacenamiento de destino motor.