Ein allgemeines Beispiel für das Repository-Muster in WordPress
Meiner Erfahrung nach beeinflusst die Art und Weise, wie wir zuerst mit dem Repository-Entwurfsmuster interagieren, oft, wie wir über das Muster denken. (Die ganzen ersten Eindrücke sind bleibende Eindrücke, oder?)
Der Zweck dieses Posts ist es zu zeigen, wie es in WordPress implementiert werden kann, speziell wenn objektorientierte Plugins geschrieben werden, um Daten zu lesen (das Schreiben von Daten wird möglicherweise in einem anderen Post behandelt), aber bevor ich das tat, habe ich versucht, ein paar Konsistenzen zwischen den zu finden Variationen des Musters, das ich gesehen habe.
Im Allgemeinen denke ich, dass ein Repository-Muster Folgendes tun sollte:
- bieten einen einzigen Ort zum Lesen von Daten,
- die Einzelheiten des Zugriffs auf die Daten abstrahieren,
- und haben dafür eine konsistente Schnittstelle.
Das bedeutet, dass alles, was Sie aus der Anwendung abrufen müssen, aus der Datenbank abgerufen werden kann. Aber wie es abgerufen wird, kann als Blackbox betrachtet werden. Das ist Sache des Entwicklers, der das Muster implementiert.
Und für diejenigen, die diesen Beitrag lesen, sind das höchstwahrscheinlich wir.
Das Repository-Pattern in WordPress
Vor ein paar Jahren habe ich über das Repository-Muster geschrieben und ein konkretes Beispiel gegeben. Es ist immer noch relevant, aber der Zweck dessen, was ich in diesem Beitrag behandeln möchte, ist ein bisschen anders.
Anstatt eine bestimmte Implementierung zu zeigen, die in einem tatsächlichen Beispiel verwurzelt ist, möchte ich lieber argumentieren, wie wir dieses Muster in unserer täglichen Arbeit anwenden können.
Die beiden Dinge, die Sie beim Lesen beachten sollten, sind:
- aus Sicht des Benutzers spielt der zugrunde liegende Datenspeicher keine Rolle,
- Aus der Sicht des Entwicklers ermöglicht uns das Muster, mit mehreren Datenquellen zu arbeiten und auch einen Musterdatenspeicher zu simulieren, damit wir die Daten auf Einheiten testen können.
Bei der Implementierung des Musters spielt es keine Rolle, woher die Daten kommen. Zumindest solange Sie der Entwickler oder das Client-Objekt sind, das es aufruft. Der Datenspeicher kann eine Datenbank, eine Reihe von API-Funktionen oder eine Kombination aus beidem sein.
Nehmen wir also an, Sie arbeiten mit einem benutzerdefinierten Post-Typ für Events und Sie arbeiten auch mit Post-Metadaten und Optionen, die sich auf so etwas wie Events beziehen.
Sie können Folgendes tun:
- den Namen der Veranstaltung erhalten,
- Informationen über den Ort der Veranstaltung finden,
- Abrufen des ersten Beitragstyps und -status, sortiert nach seiner ID
Alle diese Informationen können an verschiedenen Orten verstreut sein und die Art und Weise, wie sie abgerufen werden, kann unterschiedlich sein.
1 Abrufen des Ereignisnamens
Wenn wir mit einem benutzerdefinierten Beitragstyp arbeiten und den Ereignisnamen abrufen müssen, können wir dazu die ID eines Beitrags und eine der API-Funktionen von WordPress verwenden.
Dies ist ein Fall, in dem der Datenspeicher immer noch von uns abstrahiert wird und stattdessen die vorhandene WordPress-API nutzt.
2 Abrufen des Veranstaltungsortes
In diesem Fall können wir davon ausgehen, dass der Veranstaltungsort manuell eingegeben oder möglicherweise von einer Drittanbieter-API abgerufen wurde. Und da der Ort mit einem bestimmten Ereignis verknüpft ist, kann er sich in der Post-Metadatentabelle befinden.
Auch hier können wir es mit bereits vorhandenen API-Funktionen abrufen; In solchen Situationen ist es jedoch sinnvoll, eine Hilfsfunktion zu haben, da wir wahrscheinlich auch auf andere Metadaten zugreifen werden.
Also zuerst der Helfer :
Und dann die Funktion, die den Helfer verwendet, um den Ort zu erhalten :
Aber in diesen beiden Beispielen verwenden wir immer noch vorhandene API-Funktionen. Was ist mit dem Fall, dass wir mit der Datenbank sprechen müssen?
3 Abrufen einer einzelnen Beitrags-URL
In diesem Fall kommunizieren wir direkt mit der WordPress-Datenbank. Wenn Sie mit dem $wpdb- Objekt und SQL vertraut sind, wird dies keine große Sache sein.
Wenn dies nicht der Fall ist, empfehle ich, sich über die Prepare-Funktion sowie die Funktion get_results zu informieren .
Vor diesem Hintergrund können wir eine Abfrage schreiben, die Folgendes tut:
- alle Beiträge abrufen, bei denen die ID mit einem bestimmten Wert übereinstimmt, der Beitragstyp und der Beitragsstatus ein bestimmter Wert sind, und wir ordnen die Ergebnisse nach aufsteigendem Wert der ID,
- Als Nächstes verwenden wir die Ergebnisse dieser Abfrage, um einen einzelnen Wert zu erhalten.
Und wir können dies tun, indem wir sowohl auf die Datenbank zugreifen als auch eine verschachtelte Abfrage schreiben:
Und dann kann all dies in einer einzigen Klasse gekapselt werden, die beispielsweise das Event Repository (oder EventRepository) wäre.
Ich werde jedoch mehr darüber in einem Folgebeitrag haben. Nämlich, wie man damit umgeht, welche Funktionen wohin gehören, die Namenskonventionen und wie man mit Persistenz umgeht, falls Sie das auch in Ihr Repository einführen möchten.
Repository definiert
Beachten Sie vor allem Folgendes:
Das Repository-Muster maskiert, wie die Daten abgerufen werden, bietet jedoch eine konsistente Möglichkeit, wie die Daten, mit denen es verknüpft ist, abgerufen werden können.
Einige können auch hinzufügen, wie es abgerufen und geschrieben werden kann, aber vielleicht werde ich das in einem anderen Beitrag besprechen.