Magento 2: Différence entre les modèles et les modèles de données

Je suis conscient que Magento 2 a introduit des modèles de données dans le cadre de l'architecture du contrat de service. Les modèles de données implémentent généralement des interfaces définies dans Api / Data / d'un module.

Mais Magento semble également avoir conservé les anciens modèles.

Prenons un exemple pour module-client.

• Interface de modèle de données définie dans Api / Data / CustomerInterface.php
• L'interface ci-dessus est implémentée dans Model / Data / Customer.php
• Le modèle de données a toutes les fonctions getter et setter pour les variables client, comme on pourrait s'y attendre
• En plus de ce qui précède, il existe également un Model / Customer.php. Cela a aussi la fonction getter et setter. Cela ressemble plus à un modèle Magento 1 qui se connecte au ResourceModel (Model / ResourceModel / Customer.php)
• Dans Model / ResourceModel / CustomerRepository.php, diverses fonctions collectent les données du modèle Magnento 1, les transfèrent vers le modèle de données, puis renvoient le modèle de données.

Pourquoi a-t-on besoin de l'ancien modèle? Pourquoi le modèle de données ne peut-il pas se connecter directement au ResourceModel?

Mon explication:

Il est très difficile de comprendre la différence entre un modèle et un modèle de données. Si je dois dire en quelques mots, je pourrais dire qu'un modèle représente le moteur et un modèle de données représente ses informations .

Dans votre exemple, avec l'entité client, vous pouvez voir par exemple comment la méthode authenticateou validatePasswordsont conservées dans le modèle client car elles font partie du moteur et ne vont pas traiter directement les informations. D'un autre côté, des méthodes telles getExtensionAttributesque la gestion des informations sont conservées dans le modèle de données.

Je pense que c'est juste une meilleure gestion de projet, tout comme la division entre les modèles et les modèles de ressources, vous pourriez vous demander pourquoi vous en avez également besoin.

Pourquoi vous en avez besoin:

Si vous souhaitez exposer les informations client (par exemple) à l'aide de l'API, vous aurez besoin d'une interface ( \Magento\Customer\Api\Data\CustomerInterface) avec des getters définissant tous les attributs de votre entité, et si vous avez une autre méthode getter ne représentant pas les informations que vous souhaitez exposer (par exemple: getRandomConfirmationKey), vous avez un problème!

C'est pourquoi, dans mon exemple, getRandomConfirmationKeyfait partie du modèle ( \Magento\Customer\Model\Customer), tandis que getFirstnamefait partie du modèle de données.

Une règle rapide pourrait être:

• Si votre méthode représente une colonne de table, un attribut ou une information d'entité de quelque nature que ce soit, vous devez alors passer au modèle de données .
• Si votre méthode est une "action" sur les informations, elle gère les informations ou vous les déclarez dans webapi.xml , alors ce devrait être une méthode modèle .

PUBLIER:

En quelques mots: considérez un modèle de données presque comme un DTO.

En ajoutant à la réponse @ Phoenix128_RiccardoT, il convient de noter que les référentiels (c.-à-d. MagentoCms\Api\BlockRepositoryOu Magento\Customer\Api\CustomerRepositoryInterface) s'attendent également à ce que vous fournissiez un modèle de données et non un modèle régulier. Les modèles de données sont une couche d'abstraction sur les modèles standard qui expose uniquement les données fournies par l'entité. Toutes les "actions" sur ces données sont déplacées ailleurs.

Cela ressemble un peu à l'idée d'entité dans Symfony2 et Symfony3 où les entités ne contiennent que des données et toute manipulation de données a lieu dans le gestionnaire d'entités. Dans Magento2, ce rôle, je crois, a été confié aux référentiels.

Les anciens modèles sont toujours avec nous car ils ont développé magento2. Ils ne sont évidemment pas partis d'un index.php vide mais ont réutilisé du code de M1. Lorsque vous jetez un oeil à des méthodes de modèle standard ( load(), save()et delete()) tous sont marqués comme deprecated. C'est parce que ce travail est déplacé vers des référentiels (étant entendu que dans certains cas, tout le référentiel appelle maintenant cette save()méthode de modèle standard, mais la route me semble claire).

Les modèles encapsulent la logique métier indépendante du stockage, ils ne connaissent pas les moteurs ou les instances de base de données, dans Magento 2 les modèles de données sont des objets de transfert de données (DTO), la mise en œuvre des interfaces spécifiques DTO (modèle de données) pour les modèles Magento CRUD (le modèle ) détermine les méthodes de classe disponibles via Magento WebAPI.

Model/Data/Customer.phpdétermine les méthodes disponibles pour l'API, tandis que l' Model/Customer.phpimplémentation héritée de type Magento 1 de getters et setters personnalisés est disponible pour les opérations non-API.

Model/ResourceModel/CustomerRepository.php fait partie d'une nouvelle fonctionnalité introduite dans Magento 2 - Contrats de service, il fonctionne avec la combinaison de DTO (Data Models).

Comme nous savons que Magento ORM se compose des modèles, des modèles de ressources et des collections et dépend de la base de données, le but d'un contrat de service est de masquer la logique de stockage afin qu'un client connecté au référentiel (contrat de service) ne se soucie pas du stockage cible. moteur.