Die Repository-Muster-Grundlage

Immer wenn Sie an einem größeren Projekt arbeiten, das auf WordPress basiert, sind die Chancen, dass Sie mit mehr als einer einzigen Datenquelle – also der WordPress-Datenbank – arbeiten, höher als normal. Beispielsweise arbeiten Sie möglicherweise an einem Projekt, das Informationen koordinieren muss aus:

• die WordPress-Datenbank,
• ein Helpdesk-Ticketsystem,
• ein System zum Importieren von Inhalten,
• eine andere Drittanbieter-API,
• und möglich mehr.

Und wenn dies passiert, kann es etwas umständlich werden, Code zu schreiben, der es einfach macht, Informationen von diesen verschiedenen Orten abzurufen. Davon sprechen Entwickler normalerweise, wenn sie sich auf den Umgang mit „Ebenen” in ihrer Anwendung beziehen. Das heißt,

• es gibt Schichten zur Präsentation von Informationen für den Benutzer,
  Schichten zur Handhabung der Geschäftslogik (oder Domänenlogik),
• Schichten für die Kommunikation mit APIs,
• und Schichten zum Speichern von Daten.

Ehrlich gesagt müssen Sie keine Vielzahl von Datenspeichern im Auge behalten, um eine Ebene zu erstellen, die das Senden und Abrufen von Daten aus der Datenbank erleichtert, das ist nur dann der Fall, wenn es häufiger vorkommt. Sie können bei der Implementierung des Repository-Musters genauso effektiv mit einem einzigen Datenspeicher wie der WordPress-Datenbank arbeiten.

Unabhängig davon, ob Sie eine größere Website, Webanwendung oder ein Plugin erstellen, ist die Implementierung des Repository-Musters etwas, das sich in Bezug auf Wartung, Klarheit des Codes und Trennung von Bedenken auszahlen kann.

Aber wie könnte dies in WordPress implementiert werden? Es ist nicht sehr herausfordernd, aber zuerst lohnt es sich, eine Repository-Grundierung zu überprüfen, bevor Sie sich in irgendeinen Code stürzen.

Ein Repository-Muster-Primer

Bevor Sie sich eine tatsächliche Implementierung in WordPress ansehen, ist es wichtig zu verstehen, was das Repository ist, wie es definiert ist, was es bietet und eine generische Implementierung davon. Ich werde am Ende des Artikels etwas weiter lesen, aber bis dahin werde ich meine allgemeine Sicht auf das Muster hier behandeln.

Erstens kann eine Implementierung dieses Musters für Anfänger komplizierter als nötig werden. Das soll nicht heißen, dass das eigentliche Muster nicht verstehenswert ist, aber wenn Sie sich nur damit anfreunden wollen, bin ich kein Fan davon, Leser ins kalte Wasser zu werfen. Ich glaube nicht, dass es der beste Weg ist, um zu lernen.

Stattdessen lohnt es sich, das Problem zu zerlegen und es dann etwas eleganter wieder aufzubauen. Das werde ich also anstreben.

Ein Wort zur Entkopplung

Wenn wir von objektorientierter Programmierung sprechen, sprechen wir oft von der Idee, Teile des Systems zu „entkoppeln”. Wenn Sie sich mit Kopplung und Kohäsion auskennen, wissen Sie warum.

Aber wenn nicht, genügt es zu sagen, dass je stärker die Komponenten Ihres Systems gekoppelt sind, desto schwieriger sind sie zu ändern. Sie wissen zu viel voneinander. Das heißt, wenn Sie einen der Aspekte des Systems ändern, wird dies wahrscheinlich einen anderen Teil des Systems beeinflussen oder kaskadieren, was Sie nie beabsichtigt hatten. Dann müssen Sie viel mehr Zeit damit verbringen, all diese anderen „Berührungspunkte” im gesamten System zu beheben, die nicht notwendig sein sollten.

Die Implementierung verschiedener Strategien, wie z. B. des Repository-Musters, kann dabei helfen, Teile des Systems zu entkoppeln. Ein typisches Beispiel: Die Präsentationsschicht weiß nicht, wie der zugrunde liegende Datenspeicher organisiert ist. Es muss kein SQL können. Es muss nicht wissen, dass es sich um eine Datenbank handelt. Stattdessen muss es nur wissen, wie es mit dem Repository kommuniziert.

Schön, oder?

Dies bedeutet, dass Sie den Backend-Datenspeicher austauschen können und, vorausgesetzt, Ihre API ist solide; Ihre Anwendung funktioniert weiterhin mit wenig bis gar keinen Änderungen. Und das bedeutet es, wirklich entkoppelt zu sein.

Eine Implementierung des Repository-Musters

Wie sieht also das Repository-Muster aus? Wie bei den meisten Designmustern gibt es eine generische Form des Musters, und das ist immer hilfreich, aber ich denke, es hilft auch denen von uns, die mit WordPress arbeiten, um zu sehen, wie es im Kontext von WordPress funktionieren könnte. 

Daher möchte ich zuerst das Muster selbst aufschlüsseln und dann ein Beispiel dafür geben, wie es bei der Arbeit mit WordPress aussehen könnte.

Eine generische Implementierung des Repository-Musters

Die tatsächliche Implementierung des Repository-Musters ist ziemlich einfach. Tatsächlich bin ich mir nicht sicher, ob es so hilfreich ist, weil es nur zeigt, wie die Datenspeicher, das Repository und der Rest der Anwendung miteinander interagieren.

Verstehen Sie mich nicht falsch: Ich bin total für konzeptionelle Modelle, wie Dinge organisiert sind. Persönlich hilft es mir, beim Erstellen über die Struktur einer Anwendung nachzudenken, aber wenn es zu allgemein ist, hilft es nicht viel.

Aber um zu einer konkreten Umsetzung zu kommen, müssen wir doch irgendwo anfangen, oder? Also fange ich auf dem höchstmöglichen Niveau an und arbeite mich nach unten.

Wie Sie im obigen Bild sehen können, haben Sie einige Datenspeicher, die alle über das Repository gelesen werden, und dann fragt die Anwendung das Repository ab, das wiederum Informationen aus dem Datenspeicher abruft.

Ja, es gibt Optionen, um Informationen zwischenzuspeichern, den Cache ungültig zu machen und all diese lustigen Dinge. Aber es liegt außerhalb des Geltungsbereichs eines primären des Repositorys. Also werde ich diesen speziellen Weg vorerst nicht gehen. Vielleicht in einem zukünftigen Beitrag (sollte sich dieser für Sie als nützlich erweisen).

Das Repository-Pattern in WordPress

Lassen Sie uns also einen Blick auf eine grundlegende Implementierung werfen, wie dies in einer Standard-WordPress-Installation aussehen könnte. Das heißt, alles, was wir haben, ist der Datenspeicher. Wir kommunizieren mit nichts anderem, aber wir möchten sicherstellen, dass alles, was mit der Datenbank oder der API verbunden ist, vom Repository verarbeitet wird

Das würde in etwa so aussehen:

So könnte es mit WordPress aussehen

Und das lässt sich noch weiter abstrahieren. Vielleicht gibt es ein Post-Repository oder ein Benutzer-Repository. Persönlich bin ich ein Fan davon, ein Repository für jeden Entitätstyp zu haben, weil es hilft, verwandte Geschäftslogik zu enthalten, ohne diese großen Klassen zu erstellen, die alles wissen (und das unnötigerweise).

Das könnte also so aussehen:

Ein Paket von Repositories

Dann lassen Sie uns noch eine Ebene höher gehen und sagen, dass Sie mit der Twitter-API, der ZenDesk-API, der WordPress-Benutzer-API und der WordPress-Post-API arbeiten. Dann was? Es gibt noch mehr Depots.

Vielleicht sind sie in ihrem Namensraum enthalten (was sie sein sollten), vielleicht implementieren sie eine gemeinsame Schnittstelle (für die es einen Grund dafür gibt), aber während der Entwicklungszeit denke ich, dass es wichtig ist, explizit anzugeben, welches Repository Sie verwenden also so klar wie möglich.

Das heißt, verwenden Sie kein generisches und lassen Sie es die Laufzeit herausfinden:

Seien Sie stattdessen explizit:

Das mag sich nach viel anfühlen. Ich weiß nicht, ob Sie das erleben, aber es gibt ein komisches Gefühl in der objektorientierten Programmierung, wo wir die kleinen, fokussierten Klassen erstellen wollen, aber es erzeugt viele Dateien.

Sie haben also diese ordentlich eingerichteten Dateien, von denen jede etwas Kleines und Zweckmäßiges tut. Lassen Sie nicht zu, dass die Anzahl der Dateien, aus denen ein Projekt besteht, den Eindruck erweckt, dass Sie eine schlechte Architektur haben.

Fazit

Dies ist die Einführung in das Repository-Muster. Natürlich gibt es Code, der damit einhergeht, aber bevor ich mich mit diesem Teil befasse – denn im Code gehen Dinge leicht bei der Übersetzung verloren – wollte ich sicherstellen, dass ich dabei behilflich bin, eine Illustration bereitzustellen, um ein konzeptionelles Modell für die Funktionsweise des Musters zu entwickeln.

Von hier aus können wir beginnen, über eine Implementierung des Musters zu sprechen. Im nächsten Beitrag oder den nächsten paar Beiträgen werde ich genau das tun.

Zögern Sie in der Zwischenzeit nicht, Kommentare oder Fragen zu den hier behandelten Themen zu hinterlassen.

Verwandte Lektüre

• Das Repository-Muster über 8th Light
• Das Repository-Pattern über MSDN
• Eine Implementierung des Repository-Musters