Magento 2: Co to jest umowa serwisowa

Czy w Magento 2 jest konkretny przykład czegoś, co zostało zbudowane przy użyciu koncepcji umowy serwisowej ? Często widywałem ten termin, ale patrząc na Magento 2 w obecnej postaci, nie jest dla mnie jasne, czy umowy serwisowe są bardziej przewodnimi zasadami, czy też faktycznie wiążą się z konkretnymi implementacjami rzeczy w Magento 2.

Jak rozumiem, wszystkie interfejsy zdefiniowane w folderze API są umowami serwisowymi. Zatem wszędzie tam, gdzie używany jest interfejs zamiast faktycznej implementacji klasy, korzysta on z umowy serwisowej.

Przykładem może być ta implementacja wtyczki tutaj https://github.com/magento/magento2/blob/2.3.2/app/code/Magento/GiftMessage/Model/Plugin/OrderGet.php#L78

To używa

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

zamiast \Magento\Sales\Model\Order

Usługi (zwane również umowami serwisowymi) są jednym z naszych głównych wzorców rozwoju w Magento 2, aby zapewnić stabilne interfejsy dla łatwej personalizacji / rozbudowy. Przyjmują 2 formy w bazie kodu (oba są opatrzone adnotacjami @apiw klasie lub metodach klasy w celu zidentyfikowania ich jako stabilnych interfejsów, które można dostosować i / lub ujawnić jako interfejs API sieci Web): API lub SPI. Interfejsy API są zdefiniowane w folderze API i przyjmują dwie formy - w pełni przebudowaną usługę i tylko moduł tylko API.

W pełni refaktoryzowane usługi znajdują odzwierciedlenie w modułach Klient, Zapasy, Podatek i Kwota * (Klient jest usługą do emulacji, Kwota ma jeszcze obszary, które wymagają refaktoryzacji). Moduł tylko API można zobaczyć w Katalogu, Sprzedaży i CMS. W przypadku w pełni zreformowanych usług wystarczy wykonać wtyczkę do metody usługi, aby wpłynąć zarówno na api internetowe, jak i na GUI. W przypadku modułów tylko API musisz podłączyć metodę usługi, aby wpływać na api internetowe, ale nadal będziesz musiał dokonać 1x dostosowań stylu, aby wpłynąć na GUI.

Interfejsy SPI to w zasadzie interfejsy w kodzie opatrzone adnotacjami, @apiktóre są zamierzonymi miejscami, które strony trzecie wdrożyłyby, aby zapewnić pewne funkcje biznesowe. Przykład SPI ( CarrierInterface) zdefiniowanej w module wysyłkowym, który zaimplementujesz w module wysyłkowym (tj. Ups).

Struktura usług zapewnia szereg interesujących korzyści. Łatwa ekspozycja jako interfejs WWW (i nadchodzące po 2.0 za pośrednictwem kolejek wiadomości) vi webapi.xmlkonfiguracja (w stylu SOAP i REST). W najbliższym czasie (post 2.0) dodamy wywołania API (połączenia synchroniczne lub Webhooki, jeśli skonfigurowano je do uruchamiania asynchronizacji, wysyłania wiadomości), którymi można zarządzać / ujawniać je poprzez konfigurację. Bezpieczniejsza instalacja / aktualizacje - możesz programowo zidentyfikować problematyczne sytuacje (2 lub więcej rozszerzeń implementujących ten sam interfejs). Usprawnione dostosowywanie, które wpływa zarówno na interfejs API, jak i interfejs GUI, ponieważ istnieje tylko jedna metoda / usługa do dostosowania (w przypadku w pełni zreformowanego modułu lub nowych modułów / usług stworzonych przez społeczność).

Sprawdź zastosowania tych metod:

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

Umowy serwisowe Magento

Zasadniczo umowy serwisowe są tylko zestawem interfejsów i klas, które chronią integralność danych i ukrywają logikę biznesową. Powodem, dla którego klienci będą chcieli to wykorzystać, jest fakt, że umowa pozwala na rozwój usługi bez wpływu na jej użytkowników.

Uaktualnienie to jest ważne, ponieważ zmienia sposób interakcji użytkowników z różnymi modułami. W Magento 1 nie było dobrych sposobów interakcji z innymi modułami. Dzięki umowom serwisowym w Magento 2 możesz łatwo uzyskiwać dostęp do danych i nimi manipulować, nie martwiąc się o strukturę systemu.

Architektura umowy serwisowej

Warstwa usług ma dwa różne typy interfejsów: interfejsy danych i interfejsy usług. Interfejsy danych to obiekty, które zachowują integralność danych przy użyciu następujących wzorców:

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.

Interfejsy usług zapewniają zestaw metod publicznych, z których może korzystać klient. Istnieją trzy podtypy interfejsów usług:

Repository Interfaces
Management Interfaces
Metadata Interfaces

Interfejsy repozytorium

Interfejsy repozytorium zapewniają użytkownikowi dostęp do trwałych jednostek danych. Na przykład stałymi jednostkami danych w module klienta są odbiorca, adres i grupa. To daje nam trzy różne interfejsy:

CustomerRepositoryInterface
AddressRepositoryInterface
GroupRepositoryInterface

Metody stosowane przez te interfejsy to:

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.

Interfejsy zarządzania

Te interfejsy zawierają różne funkcje zarządzania niezwiązane z repozytoriami. Oto kilka przykładów:

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

Liczba wzorów stale rośnie, a wraz z nimi niektóre z tych funkcji prawdopodobnie zostaną do nich dodane.

Interfejsy metadanych

Interfejsy metadanych dostarczają informacji o wszystkich atrybutach zdefiniowanych dla konkretnej encji. Obejmuje to również niestandardowe atrybuty, do których można uzyskać dostęp za pomocą funkcji getCustomAttribute ($ name). Te niestandardowe atrybuty obejmują:

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.

Odniesienie:

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