Hier beginnen we met de basis en leggen we uit hoe applicaties in lagen zijn opgebouwd, wat een repository is en introduceren we het repository-patroon. Vervolgens bespreken we hoe dit is geïmplementeerd in Magento 2 en wat dit betekent voor gebruikers van dit platform.
Gelaagd applicatieontwerp
Stel dat u een willekeurige applicatie hebt. Dit kan een webapplicatie, een multimedia-applicatie, enzovoort zijn. Applicaties zijn conceptueel meestal opgedeeld in lagen, niet alleen voor een beter begrip, maar ook voor een beter ontwerp en om het leven van ontwikkelaars gemakkelijker te maken.
Ongeacht het type applicatie, deze moet hoogstwaarschijnlijk communiceren met een of andere vorm van persistente data. Dit kan in de vorm van een harde schijf, een netwerk, de cloud of iets anders zijn. Dit wordt de gegevensbron genoemd. De applicatie heeft ook een presentatielaag, die verantwoordelijk is voor de interactie met de eindgebruiker en het weergeven van alle relevante informatie.
Onder de presentatielaag bevindt zich de bedrijfslogica. Deze laag wordt soms ook wel bedrijfslogica of domeinlogica genoemd. In essentie is deze verantwoordelijk voor het vertalen van de specificaties van de business in de echte wereld naar programmeerregels en datacondities.
Het kan bijvoorbeeld afdwingen dat een product, object A, een bepaald attribuut X heeft, of dat een bepaalde actie wordt uitgevoerd wanneer een bestelling voor object B wordt geplaatst. Het bepaalt hoe data kan worden aangemaakt, opgeslagen en gewijzigd.
Zoals u ziet, moet de bedrijfslogica communiceren met de gegevensbron. Maar rechtstreeks toegang krijgen tot deze data is over het algemeen geen goed idee. Het maakt het voor ontwikkelaars lastiger om zich volledig te concentreren op het correct implementeren van de logica, omdat ze moeten begrijpen hoe de gegevensbron is gestructureerd en hoe gegevens daaruit kunnen worden opgehaald.
Dit leidt meestal tot problemen zoals dubbele code, een slechte implementatie van de bedrijfslogica, moeilijkheden bij het testen van de logica en in principe een grotere kans op programmeerfouten.
Het Repository-patroon
De oplossing voor dit probleem is om een extra laag toe te voegen tussen de gegevensbron en de bedrijfslogica. Een repository is een van de manieren om dit te doen. Over het algemeen is een repository een centrale locatie waar gegevens worden opgeslagen en beheerd.
Het repository-patroon is een ontwerppatroon waarbij een repository een abstractielaag vormt, de datalaag, tussen de gegevensbron en de bedrijfslaag. Dit haalt in feite de logica voor het ophalen en mappen van de gegevens naar een model weg uit de bedrijfslaag en plaatst deze in de datalaag.
Op deze manier hoeft de bedrijfslaag zich geen zorgen te maken over het formaat van de gegevens. Dit kan een database, een SharePoint-lijst of een webservice zijn.
De repository is tevens verantwoordelijk voor de ORM-implementatie. ORM (Object-relationele mapping) is verantwoordelijk voor het mappen van objectgeoriënteerde taal naar relationele databasetaal. Met het repository-patroon is deze mapping onzichtbaar voor de bedrijfslaag. Het zou geïmplementeerd kunnen worden met LINQ to SQL of zelfs ADO.NET Entity Framework, maar het is nu de taak van de repository om zich hiermee bezig te houden.
Introductie van het Repository Pattern in Magento 2
Hoewel het concept van het repository pattern al een tijdje bestaat, werd het niet gebruikt in Magento 1 en werd het geïntroduceerd in Magento 2. Het werd geïntroduceerd omdat er enkele ingrijpende wijzigingen nodig waren in de API van Magento. Laten we deze wijzigingen eens kort bekijken.
- Modernisering van de API met REST (Representational State Transfer), terwijl achterwaartse compatibiliteit behouden blijft voor webwinkels die SOAP (Simple Object Access Protocol) gebruiken. Zowel REST als SOAP zijn communicatieprotocollen voor webservices die interoperabiliteit tussen netwerksystemen mogelijk maken. Het behouden van functionaliteit voor de oude SOAP API, de nieuwe REST API en eventuele toekomstige APIʼs. Het herstructureren van de Magento ORM-laag. Dit alles met een team dat lacunes had in de Magento 1-ervaring. Een van de belangrijkste manieren waarop het Magento-team dit alles heeft bereikt, was door het repository-patroon te implementeren. Dit heeft geresulteerd in een verbeterde algehele prestatie van het platform ten opzichte van Magento 1, omdat alle CRUD-bewerkingen (Create, Read, Update & Delete) naar de repository, oftewel de datalaag, zijn verplaatst. src="{{media url=" wysiwyg="" cms_images="" 3_what_is_the_repository_pattern_in_magento_2.jpg"}}"="" alt="Er zijn veel artikelen te vinden die repository-ontwerppatronen beschrijven, maar niet alle zijn even duidelijk in hun uitleg. De beschrijving verschilt per programmeertaal, waardoor het soms verwarrend kan zijn. Hier beginnen we met de basisprincipes en leggen we uit hoe applicaties in lagen zijn opgebouwd, wat een repository is en introduceren we het repository-patroon. Vervolgens bespreken we hoe het is geïmplementeerd in Magento 2 en wat het betekent voor gebruikers van dit platform.">
Hoe werkt het?
Dit kleine voorbeeld laat zien hoe de bedrijfslogica en het ophalen en opslaan van gegevens gescheiden zijn met behulp van het repository-patroon. Het laden en opslaan van gegevens gebeurt in principe via de repository, terwijl het benaderen of wijzigen van een gegevensveld door de bedrijfslogica wordt gedaan. De repository zet de gegevens, ongeacht het formaat waarin ze in de gegevensbron zijn opgeslagen, om naar het $model-object, dat lokaal is voor de bedrijfslaag.
// Gegevens laden vanuit permanente opslag $model = $modelRepository->loadById($id); // Gegevens lezen uit model $name = $model->getName(); // Gegevens wijzigen in model $model->setActive(true); // Wijzigingen opslaan in permanente opslag $modelRepository->save($model); Merk op dat dit voorbeeld vereenvoudigd is. Er zijn andere voorbeelden die dieper ingaan op het opzetten van klassen, het maken van objecten en het gebruik van de repository. Ons doel is hier alleen om het concept van het repository-patroon uit te leggen aan Magento 2-gebruikers die dit wellicht nieuw vinden.
De repository-patroonbenadering heeft echter één nadeel. Er is een handige functie in webpaginaʼs, met name voor mobiele apparaten, namelijk lazy loading. We noemen het lazy omdat elementen zoals afbeeldingen alleen worden geladen als ze binnen het schermgebied vallen. Dit betekent bijvoorbeeld dat wanneer u een webwinkel bezoekt, alleen de bovenste afbeeldingen worden geladen en de andere afbeeldingen worden geladen naarmate u naar beneden scrollt op uw apparaat.
In Magento 2 wordt echter, zoals in het bovenstaande voorbeeld wordt geïllustreerd, bij een laadbewerking alle data geladen en niet alleen de benodigde data. Wanneer je een Magento 2-webshop opent, duurt het laden langer omdat alle afbeeldingen uit de permanente opslag worden opgehaald.
Er zijn al enkele extensies die deze beperking omzeilen en lazy loading in Magento 2 mogelijk maken. Je kunt er een aantal vinden in de Magento Marketplace.
Conclusie
De introductie van het repository-patroon heeft de API-standaarden in Magento 2 verbeterd. Dit is gunstig voor ontwikkelaars, die nu gemakkelijker extensies kunnen aanpassen en bouwen voor het populaire e-commerceplatform.
Over het algemeen heeft deze verandering geleid tot verbeterde prestaties, functionaliteit, beveiliging en stabiliteit in Magento 2 in vergelijking met Magento 1.
