Magento 2: Qu'est-ce qu'un contrat de service

Dans Magento 2, existe-t-il un exemple concret de quelque chose qui est construit en utilisant le concept de contrat de service ? J'ai beaucoup vu ce terme, mais en regardant Magento 2 tel qu'il existe maintenant, il n'est pas clair pour moi si les contrats de service sont plus des principes directeurs, ou s'ils se rapportent en fait à des implémentations spécifiques de choses dans Magento 2.

Si je comprends bien, toutes les interfaces définies dans le dossier Api sont les contrats de service. Ainsi, partout où l'interface est utilisée au lieu de l'implémentation réelle de la classe, elle utilise le contrat de service.

Un exemple serait cette implémentation du plugin ici https://github.com/magento/magento2/blob/2.3.2/app/code/Magento/GiftMessage/Model/Plugin/OrderGet.php#L78

Il utilise

protected function getOrderGiftMessage(\Magento\Sales\Api\Data\OrderInterface $order)

au lieu de \Magento\Sales\Model\Order

Les services (également appelés contrats de service) sont l'un de nos principaux modèles de développement dans Magento 2 pour garantir des interfaces stables pour une personnalisation / extension facile. Ils prennent 2 formes dans la base de code (les deux sont annotées avec @apisur la classe ou les méthodes de classe pour les identifier comme des interfaces stables que vous pouvez personnaliser et / ou exposer comme une API web): API ou SPI. Les API sont définies dans le dossier API et prennent deux formes - un service entièrement refactorisé et juste un module API uniquement.

Les services entièrement refactorisés se reflètent dans les modules Client, Inventaire, Taxe et Devis * (le Client étant le service à émuler, Quote a encore des zones à refactoriser). Un module API uniquement peut être vu dans le catalogue, les ventes et le CMS. Pour les services entièrement refactorisés, vous ne devriez avoir à faire qu'un plugin sur la méthode de service pour avoir un impact sur les API Web et l'interface graphique. Pour les modules API uniquement, vous auriez besoin de plug-in sur la méthode de service pour avoir un impact sur les API Web, mais vous auriez quand même besoin de faire des personnalisations de style 1x pour avoir un impact sur l'interface graphique.

Les SPI sont essentiellement des interfaces dans le code annoté @apiqui sont des emplacements prévus que des tiers implémenteraient pour fournir des fonctionnalités commerciales. Un exemple de SPI ( CarrierInterface) défini dans le module Expédition que vous implémenteriez dans votre module Expédition (c'est-à-dire Ups).

Le cadre de service offre un certain nombre d'avantages intéressants. Exposition facile en tant qu'API Web (et à venir après 2.0 via des files d'attente de messages) vi webapi.xmlconfiguration (comme style SOAP et REST). À court terme (post 2.0), nous ajouterons des appels d'API (appels de synchronisation ou Webhooks s'ils sont configurés pour déclencher l'async, messages sortants) qui peuvent tous être gérés / exposés via la configuration. Installation / mises à niveau plus sûres - vous pouvez identifier par programme les situations problématiques (2 extensions ou plus implémentant la même interface). Personnalisation rationalisée qui a un impact sur les API Web et les GUI car il n'y a qu'une seule méthode / service à personnaliser (pour un module entièrement refactorisé ou de nouveaux modules / services créés par la communauté).

Vérifiez les utilisations de ces méthodes:

• \Magento\Customer\Api\AccountManagementInterface::createAccount
• \Magento\Customer\Api\CustomerRepositoryInterface::getById

Contrats de service Magento

Essentiellement, les contrats de service ne sont qu'un ensemble d'interfaces et de classes qui protègent l'intégrité des données et cachent la logique métier. La raison pour laquelle les clients voudront l'utiliser est que le contrat permet au service d'évoluer sans affecter ses utilisateurs.

La raison pour laquelle cette mise à niveau est importante est qu'elle modifie la façon dont les utilisateurs interagissent avec différents modules. Dans Magento 1, il n'y avait aucun bon moyen d'interagir avec d'autres modules. Avec les contrats de service dans Magento 2, vous pouvez accéder aux données et les manipuler facilement, sans avoir à vous soucier de la structure du système.

Architecture de contrat de service

La couche de service a deux types d'interface différents: les interfaces de données et les interfaces de service. Les interfaces de données sont des objets qui préservent l'intégrité des données en utilisant les modèles suivants:

They’re read-only, since they only define constants and getters.
Getter functions can contain no parameters.
A getter function can only return a simple object type (string, integer, Boolean), a simple type array, and another data interface.
Mixed types can’t be returned by getter functions.
Data entity builders are the only way to populate and modify data interfaces.

Les interfaces de service fournissent un ensemble de méthodes publiques qu'un client peut utiliser. Il existe trois sous-types d'interfaces de service:

Repository Interfaces
Management Interfaces
Metadata Interfaces

Interfaces de référentiel

Les interfaces de référentiel garantissent qu'un utilisateur peut accéder aux entités de données persistantes. Par exemple, les entités de données persistantes dans le module client sont Consumer, Address et Group. Cela nous donne trois interfaces différentes:

CustomerRepositoryInterface
AddressRepositoryInterface
GroupRepositoryInterface

Les méthodes de ces interfaces sont les suivantes:

Save – If there’s no ID, creates a new record, and updates what’s existing if there is one.
Get – Looks for the IDs in the database and returns a certain data entity interface.
GetList – Finds all data entities that correspond with the search criteria, then gives access to the matches by returning the search result interface.
Delete – Deletes the selected entity
DeleteById – Deletes the entity when you only have its key.

Interfaces de gestion

Ces interfaces contiennent différentes fonctions de gestion qui ne sont pas liées aux référentiels. Voici quelques exemples:

AccountManagementInterface contains functions such as createAccount(), isEmailAvailable(), changePassword(), and activate().
AddressManagementInterface checks whether an address is valid by using the validate() function.

Le nombre de modèles est en constante augmentation et, ce faisant, certaines de ces fonctions sont susceptibles de leur être ajoutées.

Interfaces de métadonnées

Les interfaces de métadonnées fournissent des informations sur tous les attributs définis pour une entité spécifique. Cela inclut également des attributs personnalisés, auxquels vous pouvez accéder avec la fonction getCustomAttribute ($ name). Ces attributs personnalisés incluent:

EAV attributes – Defined via the administration interface for a local site. They can differ according to the site, which means that they can’t be represented in the data entity interface written in PHP.
Extension attributes, for which the extension modules are used.

Référence:

https://www.interactivated.me/uk/blog/service-contracts-magento-2/