Vorteile von Repository-Mustern: Warum wir es in Betracht ziehen sollten
Gestern habe ich eine Einführung in das Repository-Muster gegeben. Kurz gesagt, es ist eines dieser Muster, die meiner Meinung nach jeder verstehen sollte, der an Middleware arbeitet, die auf WordPress aufbaut.
Wenn Sie eine Einführung in ein Muster wie dieses geben, kann es schwierig sein, dem Muster gerecht zu werden, wenn Sie Folgendes benötigen:
- stell es vor,
- erklären, wie es funktioniert,
- Leistungen abdecken,
- und geben Sie eine kleine Demo.
Aber der wirkliche Vorteil des Repositorys liegt nicht nur darin, dass es die Datenschicht vom Rest der Anwendung abstrahiert, sondern dass es einfach mit verschiedenen Datenspeichern ausgetauscht werden kann (oder sollte), ohne die API zu ändern.
In einem Fall müssen Sie beispielsweise möglicherweise Daten aus der WordPress-Datenbank abrufen, in anderen Fällen müssen Sie möglicherweise etwas von einer API eines Drittanbieters abrufen, oder vielleicht gibt es einen anderen Ort, von dem Sie Daten abrufen müssen.
Unabhängig davon ist die Idee hinter dem Repository-Muster, dass alles, was dahintersteckt, keine Rolle spielt, solange die API, die es bereitstellt, für die Schicht der Anwendung funktioniert, die es aufruft.
Und da wir eine Einführung in das Repository-Muster gegeben haben, werfen wir einen Blick auf einige der Vorteile des Repository-Musters und wie wir es im Kontext von WordPress-Projekten implementieren können.
Vorteile von Repository-Mustern
Es gibt einige Möglichkeiten, mit der Erklärung des Musters zu beginnen, also werde ich mit einem einfachen Diagramm beginnen:
Zu den Vorteilen des Repository-Musters gehört die Abstraktion des Datenspeichers
Beachten Sie im obigen Bild, dass es drei Hauptkomponenten gibt:
- die Domänenlogik (oder die Geschäftslogik), die ich als „App” bezeichnet habe,
- das Depot,
- der Datenspeicher,
Hinsichtlich der Anwendung werden die Geschäftsregeln immer relativ konsistent bleiben. Zumindest sollten sie, oder?
Das Repository fungiert als Kommunikationsmittel zwischen der Geschäftslogik und dem Datenspeicher.
Jetzt kann der Datenspeicher eine Datenbank sein, vielleicht eine Reihe von Dateien (was ich nicht empfehlen würde), eine API für einen Drittanbieter, eine Liste von Informationen, die von einer anderen Anwendung abgerufen werden, und so weiter.
Der Punkt ist, dass das Repository eine saubere API bereitstellt, in die die Geschäftslogik schreiben und aus der sie lesen kann (und dazu gleich mehr), ohne sich Gedanken darüber machen zu müssen, wohin die Daten gehen oder wie sie zurückkommen.
Das ist die Aufgabe des Depots. Und das macht es wichtig, eine konsistente API zu haben und sicherzustellen, dass sie über die Implementierungsdetails des Datenspeichers verfügt, mit dem sie interagiert.
Auf Kupplung
Abgesehen davon, dass Ihre Anwendung richtig segmentiert ist, profitiert das Repository-Muster von der Architektur, da es hilft, die Teile Ihrer Anwendung zu entkoppeln.
Das heißt, die Geschäftslogik weiß nichts darüber, wie oder wo die Daten gespeichert werden. Es weiß nur, dass es es schreiben und abrufen kann, und es kann dies mit einer sauberen API tun.
Das Repository ist für die Kommunikation des Datenspeichers verantwortlich, um die Serialisierung und den Abruf zu orchestrieren, muss jedoch eine konsistente API bereitstellen, sodass die Datenschicht keine Syntaxgymnastik durchführen muss, um ihre Informationen zu lesen und zu schreiben.
Implementierungsdetails
Bis zu diesem Punkt habe ich das Repository als konkrete Klasse dargestellt.
Die Sache ist die, dass eine Anwendung wahrscheinlich mehrere Repositories haben wird. Aus diesem Grund ist es eine gute Idee, Schnittstellen zu haben, die jedes Repository implementieren kann.
So definieren Sie den Methodenvertrag, den das Repository bereitstellt. Und so können Sie sicherstellen, dass jedes Repository mit dem richtigen Datenspeicher verbunden ist.
Eine Schnittstellenimplementierung für mehrere Repositories.
Nehmen wir also an, Ihre Anwendung muss sowohl mit der WordPress-Datenbank als auch mit einer Drittanbieter-API kommunizieren.
Im Idealfall würde die Schnittstelle einen gemeinsamen Satz von Methoden bereitstellen, aber die Implementierungsdetails würden je nach Repository variieren, da jedes Repository über die erforderlichen Anmeldeinformationen und die Fähigkeit verfügt, mit dem Datenspeicher zu kommunizieren.
Der Fortschritt zur Schnittstelle verleiht dem Muster jedoch seine Kraft. Die Domänenlogik muss sich nicht darum kümmern, wie die Informationen gespeichert oder abgerufen werden. Es ruft einfach die Methoden auf, die in der Schnittstelle definiert sind, und das erforderliche Objekt kümmert sich darum.
Es ruft einfach die Methoden auf, die in der Schnittstelle definiert sind, und das erforderliche Objekt kümmert sich darum.
Wie würde das in WordPress aussehen?
Das ist eine gute Frage (und nein, ich habe sie mir nicht ausgedacht, nur um sie selbst zu beantworten 🙂), und es kann schwierig sein, ein gutes Beispiel zu geben, weil so viel von dem, was wir tun, direkt mit der WordPress-Datenbank interagiert.
Dies bedeutet nicht, dass es keine Abstraktionen gibt, die wir verwenden können, wie z. B. Beiträge, Seiten, Benutzer oder andere benutzerdefinierte Beitragstypen, die wir erstellen möchten.
Aber WordPress bietet für vieles davon eine API. Ich sehe einen Fall, in dem beispielsweise ein Benutzer mit hinzugefügten Feldern von einem Benutzer-Repository profitieren könnte.
Oder ein benutzerdefinierter Beitragstyp mit vielen Metadaten könnte ebenfalls von einem Repository profitieren, indem die Details in das Repository eingekapselt werden.
Ein High-Level-Beispiel
Angenommen, Sie haben einen benutzerdefinierten Beitragstyp für ein Ereignis und das Ereignis hat einen Titel und eine Beschreibung, die natürlich in den Beitragstitel und den Beitragsinhalt passen würden.
Aber dann hat es Metadaten über seinen Standort, seine Startzeit, seine Endzeit und so weiter. Das könnte auch vom Repository eingekapselt werden, sodass Sie ein Ereignisobjekt haben, es an das Repository übergeben und dann das Repository die Informationen an die richtige Stelle in der Datenbank senden lassen könnten.
Und dasselbe gilt für das Abrufen der Informationen: Es weiß, wo es sie bekommt, wie es ein Event-Objekt füllt und es dann an den Aufrufer zurückgibt.
Wieder auf Kurs
Aber all dieses Gerede über ein Ereignis gerät etwas vom Thema ab, also werde ich vielleicht in einem Folgebeitrag weiter darüber sprechen und wie es in das Repository passt. Wenn man darüber spricht, gibt es natürlich viel zu berichten.
Ich würde es lieber in kleinen Schritten angehen
Kurz gesagt, wenn Sie ein Event-Repository haben, haben Sie wahrscheinlich ein Event-Objekt oder eine Event-Entität. Und wie dies in WordPress, benutzerdefinierte Beitragstypen, Metadaten usw. passt, führt zu einem Grad an Komplexität, der auf den ersten Blick entmutigend erscheinen mag, sich aber letztendlich auszahlt, wenn man mit einer größeren Webanwendung arbeitet.