Magento 2: Was ist ein Servicevertrag?

Gibt es in Magento 2 ein konkretes Beispiel für etwas, das mit dem Servicevertragskonzept erstellt wurde ? Ich habe diesen Begriff oft gesehen, aber wenn ich mir Magento 2 so anschaue, wie es jetzt existiert, ist mir nicht klar, ob Serviceverträge richtungsweisende Prinzipien sind oder ob sie sich tatsächlich auf bestimmte Implementierungen von Dingen in Magento 2 beziehen.

Soweit ich weiß, sind alle im Api-Ordner definierten Schnittstellen die Serviceverträge. Überall dort, wo die Schnittstelle anstelle der tatsächlichen Implementierung der Klasse verwendet wird, verwendet sie den Servicevertrag.

Ein Beispiel wäre diese Plugin-Implementierung hier https://github.com/magento/magento2/blob/2.3.2/app/code/Magento/GiftMessage/Model/Plugin/OrderGet.php#L78

Es benutzt

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

anstatt \Magento\Sales\Model\Order

Services (auch Serviceverträge genannt) sind eines unserer zentralen Entwicklungsmuster in Magento 2, um stabile Schnittstellen für eine einfache Anpassung / Erweiterung zu gewährleisten. Sie nehmen in der Codebasis zwei Formen an (beide sind mit gekennzeichnet)@api in der Klasse oder den Klassenmethoden , um sie als stabile Schnittstellen zu kennzeichnen, die Sie anpassen und oder als Web-API verfügbar machen können): API oder SPI. Die APIs werden im API-Ordner definiert und nehmen zwei Formen an - einen vollständig überarbeiteten Service und nur ein API-only-Modul.

Vollständig überarbeitete Services spiegeln sich in den Modulen "Kunde", "Inventar", "Steuer" und "Angebot" * wider. Ein Nur-API-Modul kann in Catalog, Sales und CMS angezeigt werden. Für vollständig überarbeitete Services sollten Sie nur ein Plug-in für die Service-Methode ausführen müssen, um sowohl die Web-API als auch die GUI zu beeinflussen. Für API-only-Module müssten Sie eine Dienstmethode einbinden, um die Web-API zu beeinflussen. Sie müssten jedoch noch Anpassungen im 1x-Stil vornehmen, um die GUI zu beeinflussen.

SPIs sind im Grunde genommen Schnittstellen innerhalb des mit Anmerkungen versehenen Codes, die von Drittanbietern @apiimplementiert werden, um einige Geschäftsfunktionen bereitzustellen. Ein Beispiel für eine CarrierInterfaceim Versandmodul definierte SPI ( ), die Sie in Ihrem Versandmodul implementieren würden (z. B. Ups).

Das Service-Framework bietet eine Reihe von interessanten Vorteilen. Einfache Belichtung als Web-API (und kommende Post 2.0 über Nachrichtenwarteschlangen) über webapi.xmlKonfiguration (als SOAP- und REST-Stil). Kurzfristig (nach 2.0) werden wir API-Call-Outs (Synchronisierungsaufrufe oder Webhooks, wenn diese so konfiguriert sind, dass sie asynchrone Nachrichten auslösen) hinzufügen, die alle über die Konfiguration verwaltet / verfügbar gemacht werden können. Sicherere Installation / Aktualisierung - Sie können Problemsituationen programmgesteuert identifizieren (zwei oder mehr Erweiterungen, die dieselbe Schnittstelle implementieren). Optimierte Anpassung, die sich sowohl auf Web-APIs als auch auf die Benutzeroberfläche auswirkt, da nur eine Methode / ein Dienst angepasst werden muss (für vollständig überarbeitete Module oder neue Module / Dienste, die von der Community erstellt wurden).

Überprüfen Sie die Verwendung dieser Methoden:

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

Magento-Serviceverträge

Im Wesentlichen sind Serviceverträge nur eine Reihe von Schnittstellen und Klassen, die die Datenintegrität schützen und die Geschäftslogik verbergen. Der Grund, warum Kunden dies nutzen möchten, besteht darin, dass der Vertrag die Weiterentwicklung des Dienstes ermöglicht, ohne die Benutzer zu beeinträchtigen.

Der Grund, warum dieses Upgrade wichtig ist, ist, dass es die Art und Weise ändert, wie Benutzer mit verschiedenen Modulen interagieren. In Magento 1 gab es keine guten Möglichkeiten, mit anderen Modulen zu interagieren. Mit Serviceverträgen in Magento 2 können Sie einfach auf Daten zugreifen und diese bearbeiten, ohne sich um die Struktur des Systems kümmern zu müssen.

Servicevertragsarchitektur

Die Serviceschicht hat zwei verschiedene Schnittstellentypen: Datenschnittstellen und Serviceschnittstellen. Datenschnittstellen sind Objekte, bei denen die Datenintegrität unter Verwendung der folgenden Muster erhalten bleibt:

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.

Service-Interfaces bieten eine Reihe von öffentlichen Methoden, die ein Client verwenden kann. Es gibt drei Subtypen von Serviceschnittstellen:

Repository Interfaces
Management Interfaces
Metadata Interfaces

Repository-Schnittstellen

Repository-Schnittstellen stellen sicher, dass ein Benutzer auf persistente Datenentitäten zugreifen kann. Persistente Datenentitäten innerhalb des Kundenmoduls sind beispielsweise Consumer, Address und Group. Dies gibt uns drei verschiedene Schnittstellen:

CustomerRepositoryInterface
AddressRepositoryInterface
GroupRepositoryInterface

Die Methoden, die diese Schnittstellen haben, sind:

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.

Management-Schnittstellen

Diese Schnittstellen enthalten verschiedene Verwaltungsfunktionen, die sich nicht auf Repositorys beziehen. Hier sind einige Beispiele:

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

Die Anzahl der Muster nimmt ständig zu, und dabei werden wahrscheinlich einige dieser Funktionen hinzugefügt.

Metadaten-Schnittstellen

Metadatenschnittstellen enthalten Informationen zu allen Attributen, die für eine bestimmte Entität definiert sind. Dies schließt auch benutzerdefinierte Attribute ein, auf die Sie mit der Funktion getCustomAttribute ($ name) zugreifen können. Diese benutzerdefinierten Attribute umfassen:

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.

Referenz:

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