Repository -Design -Muster entmystifiziert

Kernpunkte

• Das Lagermuster fungiert als Vermittler zwischen der Anwendung und der Datenquelle und ermöglicht den Aufbau einer entkoppelten Architektur, um Skalierbarkeit zu erreichen, ohne hartcodierte Abhängigkeiten zu benötigen.
• Mit diesem Modus kann sich die Anwendung auf das Empfangen und Senden von Daten zum Speichern konzentrieren, ohne auf die Details der Datenquelle zu achten. Dies geschieht durch eine öffentliche API (Schnittstelle), über die alle Benutzer mit der Datenquelle kommunizieren.
• Während das Lagermuster Vorteile wie die Trennung von Bedenken und einfache Testtests bietet, fügt es auch eine Abstraktionsebene hinzu, die kleine Anwendungen komplizieren kann.
• Implementieren des Lagermusters erfordert eine Abhängigkeitsinjektion, mit der das Data Warehouse an die Lagerschnittstelle gebunden ist. Dies vermeidet hartcodierte Kopplung und erleichtert die interface-orientierte Programmierung.

Was ist das Lagermodell?

Einfach ausgedrückt, es handelt sich um eine Implementierung der Zwischenschicht zwischen der Anwendung und der Datenquelle. Keine Partei muss sich kennenlernen, um ihre jeweiligen Aufgaben auszuführen, die es uns ermöglichen, eine entkoppelte Architektur zu haben, die in großen Anwendungen ohne hartcodierte Abhängigkeiten skaliert wird.

Warum sollten Sie darauf achten?

Verstehen wir dies mit einem Beispiel. Angenommen, wir bauen einen Online -Shop, in dem orangefarbene Süßigkeiten verkauft werden. Es ist ein kleines Geschäft, das lokale Bestände hält, sodass wir nichts Besonderes brauchen. StoreFront -Anwendungen können nur eine Verbindung zur Datenbank herstellen und basierend auf dem vorhandenen Inventar online Bestellungen aufnehmen. Dies funktioniert gut, und das Geschäft verfügt über nur ein Versorgungslager und begrenzte Betriebsbereiche. Aber was passiert, wenn das Geschäft seinen Betriebsbereich erweitern möchte? Geschäfte möchten möglicherweise in eine andere Stadt oder im ganzen Land expandieren, und ein zentrales Bestandssystem wird sehr problematisch sein.

Wenn wir das Datenmodell noch verwenden, ist unsere Anwendung etwas eng gekoppelt. StoreFront -Anwendungen müssen jede Datenquelle kennen, mit der sie interagieren muss, was ein schlechtes Anwendungsdesign ist. Die Aufgabe einer Ladenanwendung besteht darin, Kunden die Bestellung von Süßigkeiten zu ermöglichen. Die Anwendung sollte sich nicht um die Datenquelle kümmern, sondern sollte nicht alle verschiedenen Datenquellen verfolgen. Hier kommen Data Warehouses ins Spiel. Nach dem Lagermuster wird eine öffentliche API über eine Schnittstelle freigelegt, und jeder Verbraucher (in diesem Fall unsere Storefront -Anwendung) verwendet sie mit der Datenquelle. Welche Datenquelle zu verwenden oder wie man eine Verbindung dazu herstellt, hat nichts mit der Anwendung zu tun. Die Anwendung kümmert sich nur um die Daten und die von ihnen gesendeten Daten, um sie zu speichern.

Sobald das Lagermuster implementiert ist, kann für jede Datenquelle ein Lagerhaus erstellt werden. StoreFront -Anwendungen müssen keine Datenquellen mehr verfolgen. Sie verwendet einfach die Repository -API, um die von ihnen benötigten Daten zu erhalten.

Ist es ein Allheilmittel?

Nein, es ist nicht so. Wie jedes Designmuster hat es seine Vor- und Nachteile.

Profis:

• Trennung von Bedenken;
• Ermöglicht einfache Testtests, da das Repository an eine Schnittstelle gebunden ist, die die Klasse zur Laufzeit injiziert.
• Trockener (Wiederholen Sie sich nicht selbst) Das Design wird der Code zum Abfragen und Erhalt von Daten aus der Datenquelle nicht wiederholt.

Nachteile:

• Fügen Sie eine weitere Abstraktionsschicht hinzu und fügen Sie ein bestimmtes Komplexitätsniveau hinzu, wodurch sie für kleine Anwendungen zu komplex sind.

Wie geht es?

Schauen wir uns ein einfaches Code -Beispiel an. Ich werde Laravel in meinem Beispiel verwenden, um seine hervorragende Abhängigkeitsinjektionsfunktionalität zu nutzen. Wenn Sie ein modernes PHP -Framework verwenden, sollte es bereits einen Abhängigkeitsinjektions-/IOC -Behälter haben. Durch die Implementierung des Lagermusters ist eine Abhängigkeitsinjektion erforderlich, da Sie Ihr Data Warehouse ohne sie nicht an eine Lageroberfläche binden können, und die gesamte Idee ist eine interface-orientierte Programmierung, um eine hartcodierte Kopplung zu vermeiden. Wenn Sie kein Framework oder das Framework Ihrer Wahl verwenden, hat Sie keinen IOC-Container, können Sie einen IOC-Container außerhalb des Shelfs verwenden (siehe Fußnote).

Beginnen wir an. Zunächst richten wir unseren Namespace und Autoload in Komponisten ein. Öffnen Sie Composer.json und fügen Sie unserem Namespace (im Autoloadknoten, unmittelbar nach ClassMap) PSR-4-Autoladung hinzu.

    "autoload": {
        "classmap": [
            "app/commands",
            "app/controllers",
            "app/models",
            "app/database/migrations",
            "app/database/seeds",
            "app/tests/TestCase.php"
        ],
        "psr-4": {
            "RocketCandy\": "app/RocketCandy"
        }
    },

Führen Sie nach dem Speichern composer dump-autoload -o im Terminal aus, um die automatische Belastung des neuen Namespace zu registrieren. Erstellen Sie app/RocketCandy/Repositories/OrangeCandyRepository/ in OrangeCandyRepository.php. Dies wird unsere Repository -Schnittstelle sein.

<?php
namespace RocketCandy\Repositories\OrangeCandyRepository;

interface OrangeCandyRepository {

    public function get_list( $limit = 0, $skip = 0 );

    public function get_detail( $candy_id = 0 );

}

Jetzt, da wir die Schnittstelle haben, können wir ein Repository erstellen. Erstellen Sie app/RocketCandy/Repositories/OrangeCandyRepository/ in CityAOrangeCandyRepository.php.

<?php
namespace RocketCandy\Repositories\OrangeCandyRepository;

class CityAOrangeCandyRepository implements OrangeCandyRepository {

    public function get_list( $limit = 0, $skip = 0 ) {
        // 查询数据源并获取糖果列表
    }

    public function get_detail( $candy_id = 0 ) {
        // 查询数据源并获取糖果详情
    }

}

Um das CityAOrangeCandyRepository -Repository an die OrangeCandyRepository -Schinschnittstelle zu binden, verwenden wir den IOC -Container von Laravel. Öffnen Sie app/start/global.php und fügen Sie Folgendes zum Ende der Datei hinzu.

//OrangeCandyRepository
App::bind(
    'RocketCandy\Repositories\OrangeCandyRepository\OrangeCandyRepository',
    'RocketCandy\Repositories\OrangeCandyRepository\CityAOrangeCandyRepository'
);

Hinweis: Ich habe nur IOC -Bindungen in global.php zur Demonstration platziert. Im Idealfall sollten diese in ihre eigenen separaten Dateien platziert werden, in denen Sie alle IOC -Bindungen einfügen und diese Datei hier in global.php laden können, oder Sie können einen Dienstanbieter erstellen, um jede IOC -Bindung zu registrieren. Sie können hier mehr lesen.

Jetzt können wir das Repository über die Schnittstelle verwenden. In app/controllers/ befindet sich in CandyListingController.php.

    "autoload": {
        "classmap": [
            "app/commands",
            "app/controllers",
            "app/models",
            "app/database/migrations",
            "app/database/seeds",
            "app/tests/TestCase.php"
        ],
        "psr-4": {
            "RocketCandy\": "app/RocketCandy"
        }
    },

Hier injizieren wir die OrangeCandyRepository -Schinschnittstelle in unseren Controller und speichern seine Objektreferenz in einer Klassenvariablen, die jetzt von jeder Funktion im Controller verwendet werden kann, um Daten abzufragen. Da wir die OrangeCandyRepository -Schinschnittstelle an das CityAOrangeCandyRepository -Repository binden, wird es genau so sein, wie wir das CityAOrangeCandyRepository -Repository direkt verwenden.

Jetzt sind die Art und Art der Datenquelle die einzigen Bedenken von CityAOrangeCandyRepository. Unsere Anwendung kennt nur die OrangeCandyRepository -Kinterface und ihre exponierte API und jedes Repository, das sie implementiert, diese API. Das Lager wird zur Laufzeit aus dem IOC -Container analysiert, was bedeutet, dass die Schnittstellenlagerbindung nach Bedarf festgelegt werden kann Die Datenquelle kann jetzt eine Datenbank, Webdienste oder eine inter-dimensionale Hyperdata-Pipeline sein.

Nicht alle Fälle gelten

Wie ich in den Nachteilen des Repository -Musters erwähnt habe, fügt es der Anwendung eine gewisse Komplexität hinzu. Wenn Sie also eine kleine Anwendung vornehmen und nicht sehen, dass sie sich so weit entwickelt, dass sie groß ist (möglicherweise müssen mehrere Datenquellen aufgerufen werden), ist es besser, sie nicht zu implementieren und sich an das Datenmodell im alten Stil zu halten. Etwas zu verstehen ist anders als zu wissen, wann man es benutzt. Dies ist ein sehr bequemes Designmuster, das bei der Erstellung von Anwendungen viele Probleme spart und wenn Sie Anwendungen pflegen oder erweitern (oder reduzieren) müssen, jedoch kein Allheilmittel für alle Anwendungen.

Ich habe Laravel -spezifischen Code verwendet, um die obige Implementierung zu demonstrieren, aber er ist für jeden guten IOC -Container ziemlich einfach und ähnlich. Irgendwelche Fragen? Bitte machen Sie es in den Kommentaren unten.

Fußnote:

• Folgende IOC -Containerbibliotheken, die Sie verwenden können, wenn Ihr Framework nicht hat oder Sie das Framework nicht verwenden:

  • ornodi
  • ray.di
  • Auryn
  • Würfel
  • Bucket
  • ding

• Vorgeschlagenes Lesen:

  • Domänengetriebenes Design schnell
  • domänengetriebenes Design von Eric Evans

Häufig gestellte Fragen zum Lagermodell

(Dieser Teil des Inhalts ist mit dem Originaltext sehr zufällig. Um eine Duplikation zu vermeiden, wird er hier weggelassen. Der FAQ -Abschnitt im Originaltext hat eine umfassende Erläuterung des Lagermusters enthalten.)

Das obige ist der detaillierte Inhalt vonRepository -Design -Muster entmystifiziert. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!