Interactivated logo

Wat zijn servicecontracten in Magento 2?

Oct 31, 2018
Alle blogberichten

Quick answer

Refactor if the core structure still works. Rebuild if architecture, performance, and change-cost are already fighting growth. Not sure? Calculate the cost below first.

Signs your MVP is becoming a bottleneck

1

Every feature takes 3× longer

Your codebase has become too tightly coupled. Small product updates now create complexity across unrelated systems.

Medium → High
2

Developers avoid parts of the codebase

Some systems have become unstable enough that engineers no longer trust them. "Nobody wants to touch that module."

High
3

AI-generated code created inconsistent architecture

Duplicated logic, conflicting patterns, and over-engineered solutions with unnecessary dependencies throughout the codebase.

Medium → High
4

Onboarding new developers takes weeks

Business logic is scattered across the product. Different parts follow different conventions. Team velocity slows as headcount grows.

Medium
5

Small changes create unrelated bugs

A frontend adjustment should not break billing. The architecture has become too tightly coupled across the platform.

High
6

Testing is nearly impossible

Without reliable tests, deployments become stressful, refactoring becomes dangerous, and developers lose confidence.

High
7

Deployments feel risky every time

You no longer have a development-speed problem — you have a reliability problem. And it compounds aggressively as you scale.

Critical

Refactor vs. Rebuild vs. Incremental

Refactor codebase

Best forMaintainable but messy architecture
RiskLower
CostMedium
OutcomeFaster iteration

Rebuild software

Best forFundamentally broken systems
RiskHigh
CostHigh
OutcomeLong-term reset

Incremental migration

Best forScaling post-MVP startups
RiskMedium
CostMedium
OutcomeControlled modernization
Toen Magento 2 voor het eerst werd uitgebracht, vroegen veel mensen zich af wat servicecontracten precies zijn en of ze belangrijk zijn voor gebruikers. Tot op de dag van vandaag is dit voor sommigen nog steeds onduidelijk. Als modulair systeem introduceerde Magento servicecontracten om te voorkomen dat bedrijfslogica door de systeemlagen heen lekt. Dit is het gevolg van het feit dat externe ontwikkelaars de mogelijkheid krijgen om het framework aan te passen.

Als u niet bekend bent met wat servicecontracten in het algemeen zijn, het zijn in feite overeenkomsten tussen twee partijen: een serviceprovider en een servicegebruiker. Het contract definieert de diensten die de gebruiker ontvangt, samen met wat aanvullende informatie.

Hoe werkt dit dan met Magento?

Magento servicecontracten

In essentie zijn servicecontracten niets meer dan een set interfaces en klassen die de data-integriteit beschermen en de bedrijfslogica verbergen. De reden waarom klanten dit willen gebruiken, is dat het contract de service laat evolueren zonder de gebruikers te beïnvloeden.

Deze upgrade is belangrijk omdat het de manier verandert waarop gebruikers met verschillende modules interageren. In Magento 1 waren er geen goede manieren om met andere modules te interageren. Met servicecontracten in Magento 2 kunt u eenvoudig toegang krijgen tot gegevens en deze manipuleren, zonder u zorgen te hoeven maken over de systeemstructuur.

Architectuur van servicecontracten

De servicelaag heeft twee verschillende interfacetypen: data-interfaces en service-interfaces. Data-interfaces zijn objecten die de data-integriteit waarborgen door gebruik te maken van de volgende patronen:
  • Ze zijn alleen-lezen, omdat ze alleen constanten en getters definiëren.
  • Getterfuncties kunnen geen parameters bevatten.
  • Een getterfunctie kan alleen een eenvoudig objecttype (string, integer, Boolean), een array van een eenvoudig type en een andere data-interface retourneren.
  • Gemengde typen kunnen niet worden geretourneerd door getterfuncties.
  • Data-entiteitbouwers zijn de enige manier om data-interfaces te vullen en te wijzigen.
Service-interfaces bieden een set openbare methoden die een client kan gebruiken. Er zijn drie subtypes service-interfaces:
  • Repository-interfaces
  • Beheerinterfaces
  • Metadata-interfaces

Repository-interfaces

Repository-interfaces zorgen ervoor dat een gebruiker toegang heeft tot persistente data-entiteiten. Voorbeelden van persistente data-entiteiten binnen de klantmodule zijn Consument, Adres en Groep. Dit geeft ons drie verschillende interfaces:
  • CustomerRepositoryInterface
  • AddressRepositoryInterface
  • GroupRepositoryInterface
De methoden die deze interfaces hebben zijn:
  • Save – Als er geen ID is, wordt een nieuw record aangemaakt en wordt het bestaande record bijgewerkt als er wel een ID is.
  • Get – Zoekt naar de IDʼs in de database en retourneert een bepaalde data-entiteitinterface.
  • GetList – Vindt alle data-entiteiten die overeenkomen met de zoekcriteria en geeft vervolgens toegang tot de overeenkomsten door de zoekresultateninterface te retourneren.
  • Delete – Verwijdert de geselecteerde entiteit
  • DeleteById – Verwijdert de entiteit wanneer je alleen de sleutel hebt.

Beheerinterfaces

Deze interfaces bevatten verschillende beheerfuncties die geen verband houden met repositories. Hier zijn enkele voorbeelden:
  • AccountManagementInterface bevat functies zoals createAccount(), isEmailAvailable(), changePassword() en activate().
  • AddressManagementInterface controleert of een adres geldig is met behulp van de functie validate().
Het aantal patronen groeit voortdurend en naarmate dat gebeurt, zullen sommige van deze functies er waarschijnlijk aan worden toegevoegd.

Metadata-interfaces

Metadata-interfaces geven informatie over alle attributen die zijn gedefinieerd voor een specifieke entiteit. Dit omvat ook aangepaste attributen, die u kunt benaderen met de functie getCustomAttribute($name). Deze aangepaste attributen omvatten:
  • EAV-attributen – Gedefinieerd via de beheerdersinterface voor een lokale site. Ze kunnen per site verschillen, wat betekent dat ze niet kunnen worden weergegeven in de data-entiteitinterface die in PHP is geschreven.
  • Extensie-attributen, waarvoor de extensiemodules worden gebruikt.

Voordelen van servicecontracten

Het belangrijkste voordeel van servicecontracten is dat ze de modulariteit van Magento vergroten. Ze stellen Magento en ontwikkelaars van derden in staat om composer.json-bestanden te gebruiken om systeemafhankelijkheden te rapporteren, wat compatibiliteit met alle Magento-versies garandeert. Dit soort compatibiliteit biedt verkopers een eenvoudige manier om Magento te upgraden.

Servicecontracten zorgen bovendien voor een duurzame en goed gedefinieerde API die kan worden geïmplementeerd door extensies van derden en andere modules.

Een ander groot voordeel heeft betrekking op data-entiteiten. Databasetabellen die vaak voor deze entiteiten worden gebruikt, zijn doorgaans vrij complex. Als bijvoorbeeld bepaalde attributen in een EAV-tabel worden opgeslagen, kan een enkele data-entiteit worden gedefinieerd door MySQL-databasetabellen.

Servicecontracten bieden een veel eenvoudigere oplossing. Het datamodel is eenvoudiger dan een relationeel databaseschema. Dit geeft gebruikers de mogelijkheid om verschillende dataverzamelingen op te slaan met behulp van verschillende opslagtechnologieën.

Waar dienen builders voor?

Als je data-entiteiten nader bekijkt, zul je zien dat de enige beschikbare methoden zijn om een data-entiteitsinstantie te lezen. Hoe maak je dan een data-entiteit aan met PHP-code? Nou, daar zijn builders voor.

Dit zijn patronen die een klasse bieden met setter-methoden waarmee je de eigenschappen kunt instellen, waarna je de uiteindelijke create()-methode gebruikt om een nieuwe instantie te verkrijgen. Als je de GitHub-repository doorzoekt, zul je de builder-code niet vinden. De reden hiervoor is dat deze al automatisch voor je gegenereerd is.

Houd er rekening mee dat het onmogelijk is om de data-entiteit die je ergens vandaan hebt gekregen te wijzigen. Wat je wel kunt doen, is de populate($entity)-methode gebruiken om de attributen van de ene entiteit naar een nieuwe te kopiëren. Je kunt de attributen vervolgens wijzigen door de setter-methoden aan te roepen en daarna een nieuwe instantie te creëren.

Tot slot

Nu je beter begrijpt wat Magento 2 Service Contracts zijn, begrijp je ook waarom ze zijn geïmplementeerd. Ze zijn erg belangrijk voor het vergroten van de modulariteit van Magento.

Zodra een module een servicecontract definieert, creëert deze een goed gedefinieerde API voor andere modules. Ze stellen clients ook in staat om de REST- of SOAP-interfaces te gebruiken om bedrijfslogica beschikbaar te stellen.

Wat voor veel gebruikers waarschijnlijk nog belangrijker is, is dat servicecontracten ervoor zorgen dat modules stabiel blijven na een Magento 2-upgrade. Dit alles maakt Magento een stuk aantrekkelijker voor gebruikers, omdat deze upgrade een aantal goed gedocumenteerde tekortkomingen in de originele versie verhelpt. In de toekomst zal het aantal servicecontractpatronen toenemen. Dit is allemaal een integraal onderdeel van Magento.
You may also like
Person avatar
Person avatar
Person avatar
We Staan Voor je Klaar

Ons expertteam zit klaar - dag en nacht - om je te helpen met planning, budgetten en het realiseren van jouw idee. Naadloos. Geen stress. Geen vertraging.

Laten We Dit Samen Uitvogelen

Laten We Praten En Iets Geweldigs Bouwen Samen.

Of het nu gaat om een schaalbaar SaaS-platform, een innovatieve marktplaats, een cutting-edge eCommerce-oplossing of een gedurfd nieuw techidee - wij hebben de expertise om het realiteit te maken. Naadloos en zonder stress.Geen drama, geen bla bla - gewoon retegoede digitale oplossingen.

Interactivated solutions contact person

Roy Van Eijsselsteijn

CEO | Head of Business Development

Schrijf Een Bericht

Door het formulier te verzenden, ga ik akkoord met de regels voor de verwerking van mijn persoonsgegevens zoals beschreven in hetPrivacybeleid.

Deze site wordt beschermd door reCAPTCHA en de Google Privacy Policy en Servicevoorwaarden zijn van toepassing.