답변:
내가 이해 한 것처럼 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의 핵심 개발 패턴 중 하나이며, 쉬운 사용자 지정 / 확장을위한 안정적인 인터페이스를 보장합니다. 코드베이스에는 두 가지 형식이 있습니다 (둘 다 @api클래스 또는 클래스 메소드에 주석을 달아 웹 API로 사용자 정의하거나 노출 할 수있는 안정적인 인터페이스로 식별합니다) : API 또는 SPI. API는 API 폴더에 정의되어 있으며 완전히 리팩토링 된 서비스와 API 전용 모듈이라는 두 가지 형식을 취합니다.
완전히 리팩토링 된 서비스는 Customer, Inventory, Tax 및 Quote * 모듈에 반영됩니다 (고객이 에뮬레이션하는 서비스 인 Quote에는 리팩토링해야하는 영역이 남아 있습니다). API 전용 모듈은 카탈로그, 영업 및 CMS에서 볼 수 있습니다. 완전히 리팩토링 된 서비스의 경우 웹 API와 GUI 모두에 영향을주기 위해 서비스 메소드에서 플러그인 만 수행하면됩니다. API 전용 모듈의 경우 웹 API에 영향을 주려면 서비스 메소드에서 플러그인해야하지만 GUI에 영향을 주려면 여전히 1x 스타일의 사용자 정의를 수행해야합니다.
SPI는 기본적으로 주석이 달린 코드 내에서 인터페이스로, @api타사가 일부 비즈니스 기능을 제공하기 위해 구현할 예정입니다. CarrierInterface배송 모듈에 정의 된 배송 모듈에 정의 된 SPI ( ) 의 예 (예 : Ups).
서비스 프레임 워크는 여러 가지 흥미로운 이점을 제공합니다. webapi.xml구성 (SOAP 및 REST 스타일)을 통한 웹 API (및 메시지 큐를 통해 2.0 이후 제공)로 쉽게 노출 단기 (2.0 이후)에서는 구성을 통해 모두 관리 / 노출 할 수있는 API 호출 (동기 호출 또는 비동기를 발생하도록 구성된 경우 웹 후크, 메시지 출력)을 추가합니다. 보다 안전한 설치 / 업그레이드-프로그래밍 방식으로 문제 상황 (동일한 인터페이스를 구현하는 2 개 이상의 확장)을 식별 할 수 있습니다. 커스터마이징 할 메소드 / 서비스가 하나만 있으므로 웹 API와 GUI 모두에 영향을주는 간소화 된 커스터마이징 (커뮤니티가 완전히 리팩터링 한 모듈 또는 새 모듈 / 서비스 용).
마 젠토 서비스 계약
기본적으로 서비스 계약은 데이터 무결성을 보호하고 비즈니스 논리를 숨기는 일련의 인터페이스 및 클래스 일뿐입니다. 고객이이를 사용하려는 이유는 계약이 사용자에게 영향을주지 않고 서비스를 발전시킬 수 있기 때문입니다.
이 업그레이드가 중요한 이유는 사용자가 다른 모듈과 상호 작용하는 방식을 변경하기 때문입니다. 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리포지토리 인터페이스
리포지토리 인터페이스는 사용자가 영구 데이터 엔터티에 액세스 할 수 있도록합니다. 예를 들어 고객 모듈 내의 영구 데이터 엔터티는 소비자, 주소 및 그룹입니다. 이것은 우리에게 세 가지 다른 인터페이스를 제공합니다 :
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/