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 เท่านั้น

บริการที่ได้รับการปรับโครงสร้างใหม่ทั้งหมดนั้นจะแสดงให้เห็นในโมดูลลูกค้า, สินค้าคงคลัง, ภาษีและใบเสนอราคา * (ลูกค้าเป็นบริการที่เลียนแบบใบเสนอราคามีส่วนที่เหลือซึ่งจำเป็นต้องได้รับการปรับโครงสร้างใหม่) โมดูล API เท่านั้นที่สามารถเห็นได้ในแคตตาล็อกการขายและ CMS สำหรับบริการที่ได้รับการปรับโครงสร้างใหม่อย่างสมบูรณ์คุณควรทำปลั๊กอินกับวิธีการบริการเพื่อส่งผลกระทบต่อทั้งเว็บ apis และ GUI สำหรับ API เฉพาะโมดูลที่คุณต้องใช้ปลั๊กอินในวิธีการบริการเพื่อส่งผลกระทบต่อเว็บ apis แต่ยังคงต้องทำการปรับแต่งรูปแบบ 1x เพื่อส่งผลกระทบกับ GUI

SPI นั้นเป็นส่วนต่อประสานภายในโค้ดที่มีคำอธิบายประกอบ@apiที่เป็นจุดประสงค์ที่บุคคลภายนอกจะนำไปใช้เพื่อให้การทำงานทางธุรกิจบางอย่าง ตัวอย่างของ SPI ( CarrierInterface) ที่กำหนดไว้ในโมดูลการจัดส่งที่คุณจะใช้ในโมดูลการจัดส่งของคุณ (เช่น Ups)

กรอบการให้บริการมีข้อดีที่น่าสนใจมากมาย การเปิดรับอย่างง่ายเหมือนเว็บ API (และการโพสต์ 2.0 ผ่านคิวข้อความ) webapi.xmlการกำหนดค่าvi (ตามรูปแบบ SOAP และ REST) ในระยะเวลาอันใกล้ (โพสต์ 2.0) เราจะเพิ่มการโทรออก API (ซิงค์การโทรหรือ Webhooks หากกำหนดค่าให้เรียกใช้ async การส่งข้อความออก) ซึ่งสามารถจัดการ / เปิดเผยผ่านการกำหนดค่า การติดตั้ง / อัปเกรดที่ปลอดภัยยิ่งขึ้น - คุณสามารถระบุสถานการณ์ของปัญหาได้โดยทางโปรแกรม ความคล่องตัวในการปรับแต่งที่ส่งผลกระทบต่อทั้งเว็บ apis และ gui เนื่องจากมีเพียงหนึ่งวิธี / บริการในการปรับแต่ง (สำหรับโมดูลที่ได้รับการปรับโครงสร้างใหม่อย่างเต็มรูปแบบหรือโมดูล / บริการใหม่ที่สร้างโดยชุมชน)

ตรวจสอบวิธีการใช้งานเหล่านี้:

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

สัญญาบริการคุณภาพเยี่ยม

โดยพื้นฐานแล้วสัญญาบริการเป็นเพียงส่วนหนึ่งของอินเทอร์เฟซและคลาสที่ปกป้องความถูกต้องของข้อมูลและซ่อนตรรกะทางธุรกิจ เหตุผลที่ลูกค้าต้องการใช้สิ่งนี้คือสัญญาอนุญาตให้บริการพัฒนาโดยไม่ส่งผลกระทบต่อผู้ใช้

เหตุผลที่การอัพเกรดนี้มีความสำคัญเนื่องจากจะเปลี่ยนวิธีที่ผู้ใช้โต้ตอบกับโมดูลที่แตกต่างกัน ใน Magento 1 ไม่มีวิธีที่ดีในการโต้ตอบกับโมดูลอื่น ด้วยสัญญาบริการใน Magento 2 คุณสามารถเข้าถึงและจัดการข้อมูลได้อย่างง่ายดายโดยไม่ต้องกังวลกับโครงสร้างของระบบ

สถาปัตยกรรมสัญญาบริการ

ชั้นบริการมีสองประเภทอินเตอร์เฟสที่แตกต่างกัน: Data interfaces และ Service interfaces อินเทอร์เฟซข้อมูลเป็นวัตถุที่รักษาความถูกต้องของข้อมูลโดยใช้รูปแบบต่อไปนี้:

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/