interactivated blog

magento & ecommerce

Wat zijn service contracts in Magento 2?

Toen Magento 2 voor het eerst werd uitgebracht, vroegen veel mensen zich af wat service contracts waren en of ze voor gebruikers belangrijk waren. Tot op vandaag is dat voor sommigen nog steeds niet helder. Als modulair systeem introduceerde Magento service contracts om te voorkomen dat business logic lekt naar systeemlagen die beschikbaar zijn voor derde partijen om aan te passen.

Als je niet bekent bent met het concept service contract: Dit zijn overeenkomsten tussen twee partijen: de service provider en de service consumer. Het contract definieert de service die de consumer krijgt met wat aanvullende informatie.

Hoe werkt dit dan in Magento?

Service contracten zijn eigenlijk niet meer dan een verzameling interfaces en classes die de data integriteit beschermen en de business logic afschermt. Bijkomend voordeel voor de klanten is dat de service zich verder kan ontwikkelen zonder dat de gebruiker daar last van heeft.

Deze upgrade maakt het voor gebruikers mogelijk om op een andere manier met andere modules te communiceren. In Magento 1 was er eigenlijk geen goede manier om dit te doen. Met service contracts in Magento 2 is data makkelijk toegankelijk en manipuleerbaar, zonder dat je je druk hoeft te maken over de systeemstructuur.

De architectuur van service contracts

De service laag heeft twee verschillende interface types: Data interfaces en Service interfaces. Data interfaces zijn objecten die de data integriteit behouden door het gebruik van de volgende patronen:

  • Ze zijn read-only omdat ze alleen constanten en getters definiëren.
  • Getter functies kunnen geen parameters bevatten.
  • Een getter functie kan alleen een enkelvoudig object type returnen (string, integer, Boolean), een enkelvoudig array type of een andere data interface.
  • Getter functies kunnen geen gecombineerde types returnen
  • Data entity builders zijn de enige manier om data interfaces te voeden of aan te passen.

Service interfaces leveren een set public methods die de client kan gebruiken. Er zijn drie service interface subtypes:

  • Repository interfaces
  • Management interfaces
  • Metadata interfaces

Repository interfaces

Repository interfaces zorgen ervoor dat gebruikers toegang hebben tot de persistent data entities. Persistent data entities in de Customer Module zijn bijvoorbeeld: Consumer, Address en Group. Dit resulteert in drie verschillende interfaces:

  • CustomerRepositoryInterface
  • AddressRepositoryInterface
  • GroupRepositoryInterface

Deze interfaces hebben de volgende methods:

  • Save – Creëert een nieuw record als er nog geen ID is en update het record als dat er al wel is.
  • Get – Zoekt het ID op in de database en returnt een bepaalde data entity interface
  • GetList – Vindt alle data entities die overeenkomen met de zoekcriteria en geeft toegang tot de resultaten door het returnen van de result interface.
  • Delete – Verwijdert de geselecteerde entity.
  • DeletedById – Verwijdert de entity d.m.v. de key (ID).

Management interfaces

Deze interfaces bevatten verschillende management functies die lost staan van de repositories. Hier zijn een aantal voorbeelden:

  • AccountManagementInterface bevat fucnties zoals: createAccount(), isEmailAvailable(), changePassword(), en activate().
  • AddressManagementInterface controleert of een adres correct is door het gebruik van de validate() functie.

Het aantal patronen groeit continue, en al doende, is het waarschijnlijk dat deze functies er aan toegevoegd worden.

Metadata interfaces

Metadata interfaces geven informatie over de attributen die voor een specifieke entity zijn gedefinieerd. Hiertoe behoren ook de attributen waar je toegang toe hebt met de getCustomAttribute($name) functie.

  • EAV attributen – Worden gedefinieerd via de administration interface voor een lokale site. Deze kunnen per site verschillen, wat betekent dat ze niet kunnen worden weergegeven in de, in PHP geschreven, data entity interface.
  • Extension attributes, waarvoor de uitbreidingsmodules worden gebruikt.

Voordelen van service contracts

Het belangrijkste voordeel van service contracten is dat ze de modulariteit van Magento vergroten. Ze stellen zowel Magento als 3rd party ontwikkelaars in staat om composer.json files te gebruiken om systeem afhankelijkheden te rapporteren, waardoor de compatibiliteit in alle Magento versies gegarandeerd is. Deze compatibiliteit stelt ondernemers in staat om Magento makkelijk te upgraden.

Service contracten garanderen ook een duurzame en goed gedefinieerde API die makkelijk door derden partijen of andere modules geïmplementeerd kan worden.

Een ander groot voordeel heeft betrekking op data entities. Database tabellen die gebruikt worden voor deze data entities neigen complex te zijn. Als bijvoorbeeld een aantal attributen opgeslagen zijn in een EAV tabel, zul je over het algemeen aardig wat joins of meerdere SQL-queries nodig hebben om één enkele data entity uit de database te halen.

Service contracten zijn veel eenvoudiger. Het datamodel is simpeler dan dat van een relationele database schema. Dit geeft gebruikers de mogelijkheid om verschillende opslag technologieën te gebruiken om verschillende data verzamelingen op te slaan.

Waar worden builders voor gebruikt?

Als je wat beter naar data entities kijkt, zal het je opvallen dat je met de beschikbare methods alleen data kan lézen van een data entity. Dus:  Hoe kun je PHP code gebruiken om data entity te creëren? Welnu, daar zijn dus de builders voor.

Dit zijn patronen die een class een setter method geven die de mogelijkheid biedt om de properties in te stellen, waarna je de final create() method gebruikt om een nieuw record te creëren. Als je de GitHub Repo doorzoekt zul je de builder code niet vinden. Dit komt omdat ze automatisch voor je gegenereerd worden.

Bedenk dat het onmogelijk is om de data entity, die je ergens vandaan gehaald hebt, te wijzigen. Wat je wel kan doen is de populate($entity) methode gebruiken om de attributes te kopiëren van de ene naar de andere entity. Daarna kun je de attributes wijzigen door de setter methods aan te roepen en daarmee een nieuwe instantie te creëren.

Tenslotte

Nu je een beter beeld hebt bij wat Magento 2 Service Contracts zijn, begrijp je waarschijnlijk ook waarom ze geïmplementeerd zijn. Ze zijn erg belangrijk voor de verbeterde modulariteit van Magento.

Als een module eenmaal een service contract heeft gedefinieerd, creëert het een goed gedefinieerde API voor andere modules. Service Contracts stellen clients ook in staat om de REST of SOAP interfaces te gebruiken om de business logic te tonen.

Wat wellicht voor gebruikers nog belangrijker is, is, dat service contracts er voor zorgen dat modules stabiel blijven na een Magento 2 upgrade. Dit alles maakt Magento nog aantrekkelijker voor gebruikers, aangezien deze upgrade een aantal bekende tekortkomingen oplost. In de toekomst zal het aantal service contract patronen toenemen. Allemaal als integraal onderdeel van Magento.

Reactie plaatsen
  • *Verplichte velden

By interactivated • on October 31, 2018

9 Reviews

Wat onze klanten over ons schrijven

Contacteer ons
Snel contact met een van onze specialisten
Interactivated Ecommerce Netherlands
Herestraat 106,
9711 LM Groningen
Nederland
Postbus 5171
9700 GD Groningen
Nederland
+31(0)50 711 9940
KVK: 58348646
BTW: NL 852998521B01

* Vereiste velden