Magento 2: Що таке договір на обслуговування


20

Чи є в Magento 2 конкретний приклад того, що створено за допомогою концепції контракту на обслуговування ? Я багато разів бачив цей термін, але дивлячись на Magento 2 як він існує зараз, мені не зрозуміло, чи є договори на обслуговування більш керівними принципами, чи вони насправді пов'язані з конкретними реалізаціями речей Magento 2.


1
Дивіться також magento.stackexchange.com/questions/50270/…
7

Відповіді:


9

Наскільки я розумію, усі інтерфейси, визначені в папці 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 Learner

Спасибі оновлено
Крістоф у Fooman

6

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

Повністю відремонтовані послуги відображаються у модулях Замовник, Інвентар, Податки та Котирування * (Клієнт - це послуга для емуляції, Котирування - залишилися ділянки, які потребують реконструкції). Модуль, призначений лише для API, можна побачити в каталогах, продажах та CMS. Для повністю реконструйованих послуг вам слід буде лише плагін про метод обслуговування, щоб впливати як на веб-apis, так і на графічний інтерфейс. Для модулів, що відповідають лише API, вам потрібно буде додатково підключатись до сервісного методу, щоб впливати на веб-apis, але все-таки потрібно зробити налаштування стилю 1x для впливу на графічний інтерфейс.

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

Сервісна база надає ряд цікавих переваг. Легке опромінення як веб-api (та надходить повідомлення 2.0 через черги з повідомленнями) vi webapi.xmlконфігурація (як SOAP та REST) У найближчому терміні (пост 2.0) ми додамо вихідні виклики API (синхронізовані дзвінки чи Webhooks, якщо вони налаштовані для запуску асинхронізації, повідомлень із зовнішнього вигляду), якими можна керувати / відкривати через конфігурацію. Більш безпечна установка / оновлення - ви можете програмно визначити проблемні ситуації (2 або більше розширень, що реалізують той же інтерфейс). Упорядкована налаштування, яка впливає як на веб-apis, так і на gui, оскільки існує лише один метод / послуга для налаштування (для повністю відновленого модуля або нових модулів / послуг, створених спільнотою).


1
Ось кілька відео з Imagine 2015, які допоможуть надати більше контексту платформи Magento 2. magento.com/videos/imagine/… , magento.com/videos/imagine/… , magento.com/videos/imagine/… , magento.com/videos/imagine/…
Чак

1

Перевірте використання цих методів:

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

0

Договори на обслуговування Magento

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

Причина цього оновлення є важливою, оскільки вона змінює спосіб взаємодії користувачів з різними модулями. У Magento 1 не було хороших способів взаємодії з іншими модулями. Завдяки контрактам на обслуговування в Magento 2 ви можете легко отримувати доступ до даних та маніпулювати ними, не турбуючись про структуру системи.

Архітектура контракту на обслуговування

Сервісний рівень має два різні типи інтерфейсів: Інтерфейси даних та Сервісні інтерфейси. Інтерфейси даних - це об'єкти, які зберігають цілісність даних, використовуючи такі шаблони:

Theyre 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 cant be returned by getter functions.
Data entity builders are the only way to populate and modify data interfaces.

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

Repository Interfaces
Management Interfaces
Metadata Interfaces

Інтерфейси сховища

Інтерфейси сховища гарантують, що користувач може отримати доступ до стійких об'єктів даних. Наприклад, постійними суб'єктами даних у Модулі замовника є споживач, адреса та група. Це дає нам три різних інтерфейсу:

CustomerRepositoryInterface
AddressRepositoryInterface
GroupRepositoryInterface

Методи, якими користуються ці інтерфейси, є:

Save  If theres no ID, creates a new record, and updates whats 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 cant be represented in the data entity interface written in PHP.
Extension attributes, for which the extension modules are used.

Довідка:

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

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.