Magento 2: что такое сервисный контракт

Есть ли в Magento 2 конкретный пример чего-то, что построено с использованием концепции сервисного контракта ? Я часто встречал этот термин, но, глядя на Magento 2 в том виде, в каком он существует сейчас, мне не ясно, являются ли контракты на обслуживание более руководящими принципами или они действительно связаны с конкретными реализациями вещей в Magento 2.

Насколько я понимаю, все интерфейсы, определенные в папке Api, являются контрактами на обслуживание. Таким образом, везде, где используется интерфейс вместо фактической реализации класса, он использует контракт на обслуживание.

Примером может служить реализация этого плагина здесь https://github.com/magento/magento2/blob/2.3.2/app/code/Magento/GiftMessage/Model/Plugin/OrderGet.php#L78

Оно использует

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

вместо того \Magento\Sales\Model\Order

Сервисы (также называемые сервисными контрактами) являются одним из наших основных шаблонов разработки в Magento 2, чтобы обеспечить стабильные интерфейсы для легкой настройки / расширения. Они принимают 2 формы в базе кода (обе помечены с @apiпомощью класса или методов класса, чтобы идентифицировать их как стабильные интерфейсы, которые можно настроить и представить в виде веб-API): API или SPI. API-интерфейсы определены в папке API и принимают две формы - полностью переработанный сервис и только модуль только API.

Полностью реорганизованные сервисы отражены в модулях Customer, Inventory, Tax и Quote * (клиент, являющийся сервисом для эмуляции, в Quote есть оставшиеся области, требующие рефакторинга). Модуль только API можно увидеть в Каталоге, Продажах и CMS. Для полностью реорганизованных сервисов вам нужно всего лишь добавить плагин для метода сервиса, чтобы повлиять как на веб-интерфейс API, так и на графический интерфейс. Для модулей только API вам нужно подключить сервисный метод, чтобы влиять на веб-интерфейс API, но все равно нужно будет выполнить настройку стиля 1x, чтобы повлиять на графический интерфейс.

SPI - это, в основном, интерфейсы в коде, обозначенном аннотацией @api, которые предназначены для сторонних разработчиков, чтобы обеспечить некоторую функциональность бизнеса. Пример SPI ( CarrierInterface), определенного в модуле доставки, который вы бы внедрили в свой модуль доставки (например, Ups).

Сервисная структура предоставляет ряд интересных преимуществ. Простое отображение в виде веб-API (и публикация сообщения 2.0 через очереди сообщений) в webapi.xmlконфигурации vi (в стиле SOAP и REST). В ближайшей перспективе (пост 2.0) мы добавим вызовы API (синхронизированные вызовы или веб-заезды, если они настроены на запуск асинхронных сообщений), которыми можно управлять / выставлять через конфигурацию. Безопасная установка / обновление - вы можете программно определять проблемные ситуации (2 или более расширений, реализующих один и тот же интерфейс). Оптимизированная настройка, которая влияет как на веб-API, так и на графический интерфейс, поскольку есть только один метод / служба для настройки (для полностью переработанного модуля или новых модулей / служб, созданных сообществом).

Проверьте использование этих методов:

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

Сервисные контракты Magento

По сути, сервисные контракты - это просто набор интерфейсов и классов, которые защищают целостность данных и скрывают бизнес-логику. Причина, по которой клиенты захотят использовать это, заключается в том, что контракт позволяет сервису развиваться, не затрагивая его пользователей.

Это обновление важно по той причине, что оно меняет способ взаимодействия пользователей с различными модулями. В Magento 1 не было хороших способов взаимодействия с другими модулями. С контрактами на обслуживание в Magento 2 вы можете легко получать доступ к данным и манипулировать ими, не беспокоясь о структуре системы.

Архитектура сервисного контракта

Сервисный уровень имеет два разных типа интерфейса: интерфейсы данных и сервисные интерфейсы. Интерфейсы данных - это объекты, которые сохраняют целостность данных, используя следующие шаблоны:

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.

Сервисные интерфейсы предоставляют набор открытых методов, которые клиент может использовать. Существует три подтипа сервисных интерфейсов:

Repository Interfaces
Management Interfaces
Metadata Interfaces

Интерфейсы репозитория

Интерфейсы репозитория гарантируют, что пользователь может получить доступ к постоянным объектам данных. Например, постоянными объектами данных в клиентском модуле являются Consumer, Address и Group. Это дает нам три разных интерфейса:

CustomerRepositoryInterface
AddressRepositoryInterface
GroupRepositoryInterface

Методы, которые имеют эти интерфейсы:

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.

Интерфейсы управления

Эти интерфейсы содержат различные функции управления, которые не связаны с хранилищами. Вот некоторые примеры:

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

Количество шаблонов постоянно растет, и при этом некоторые из этих функций, вероятно, будут добавлены к ним.

Интерфейсы метаданных

Интерфейсы метаданных предоставляют информацию обо всех атрибутах, которые определены для конкретного объекта. Сюда также входят настраиваемые атрибуты, доступ к которым можно получить с помощью функции getCustomAttribute ($ name). Эти пользовательские атрибуты включают в себя:

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.

Ссылка:

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