リポジトリデザインパターンが分類されています-PHPチュートリアル-php.cn

Repository Design Pattern Demystified

コアポイント

倉庫パターンは、アプリケーションとデータソースの間の仲介者として機能し、分離されたアーキテクチャの構築がハードコーディングされた依存関係を必要とせずにスケーラビリティを実現できるようにします。
このモードにより、アプリケーションは、データソースの詳細に注意を払わずに保存するためにデータの受信と送信に集中できます。これは、すべてのユーザーがデータソースと通信するパブリックAPI（インターフェイス）を介して行います。
倉庫のパターンは、懸念の分離や単体テストの容易さなどの利点を提供しますが、抽象化の層も追加し、小さなアプリケーションを複雑にすることができます。
倉庫パターンを実装するには、依存関係噴射が必要であるため、データウェアハウスを倉庫インターフェイスにバインドできます。これにより、ハードコーディングされた結合が回避され、インターフェイス指向のプログラミングが促進されます。

倉庫モデルとは何ですか？

簡単に言えば、アプリケーションとデータソースの間に中間層の実装です。どちらの当事者も、それぞれのタスクを実行するためにお互いを知る必要はありません。これにより、ハードコーディングされた依存関係なしに大規模なアプリケーションで拡張するのに役立つアーキテクチャを分離することができます。

なぜあなたはそれに注意を払う必要があるのですか？

これを例で理解しましょう。オレンジ色の風味のキャンディーを販売するオンラインストアを建設しているとします。それは地元の在庫を保持する小さな店であるので、私たちは派手なものを必要としません。 StoreFrontアプリケーションは、データベースにのみ接続し、既存の在庫に基づいてオンラインで注文することができます。これは、店舗が1つの供給倉庫と限られた営業エリアしかないため、うまく機能します。しかし、店舗が営業エリアを拡大したい場合はどうなりますか？店舗は別の都市または全国に拡大したいと考えている可能性があり、中央の在庫システムを持つことは非常に面倒です。

データモデルをまだ使用している場合、アプリケーションはいくらかしっかりと結合されます。ストアフロントアプリケーションは、対話する必要があるすべてのデータソースを知る必要があります。これは、アプリケーションデザインが悪いことです。ストアフロントアプリケーションの仕事は、顧客がキャンディーを注文できるようにすることです。アプリケーションはデータソースを気にするべきではありません。すべての異なるデータソースを追跡すべきではありません。これは、データウェアハウスが作用する場所です。倉庫のパターンによると、パブリックAPIはインターフェイスを介して公開され、各消費者（この場合はストアフロントアプリケーション）がそれを使用してデータソースと通信します。使用するデータソースまたはそれに接続する方法は、アプリケーションとは関係ありません。アプリケーションは、取得するデータと保存するために送信されるデータのみを気にします。

倉庫パターンが実装されたら、データソースごとに倉庫を作成できます。 StoreFrontアプリケーションは、データソースを追跡する必要がなくなり、リポジトリAPIを使用して必要なデータを取得します。

それは万能薬ですか？

いいえ、そうではありません。すべてのデザインパターンと同様に、長所と短所があります。

長所：

懸念の分離。

短所：

どうすればよいですか？

簡単なコードの例を見てみましょう。私の例では、Laravelを使用して、その優れた依存関係噴射機能を活用します。最新のPHPフレームワークを使用している場合、依存噴射/IOCコンテナが既にあるはずです。倉庫のパターンを実装するには、依存関係の注入が必要です。なぜなら、それがなければ、データウェアハウスを倉庫インターフェイスにバインドすることができず、アイデア全体がハードコード化された結合を避けるためのインターフェイス指向のプログラミングであるためです。フレームワークを使用していない場合、または選択したフレームワークにIOCコンテナがない場合は、既製のIOCコンテナを使用できます（脚注を参照）。

始めましょう。まず、作曲家に名前空間とオートロードを設定します。 Composer.jsonを開き、PSR-4 Autoloadを名前空間に追加します（クラスマップの直後にAutoLoadノード内）。

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

ログイン後にコピー

保存後、端子で

を実行して、新しい名前空間の自動負荷を登録します。 composer dump-autoload -oinapp/RocketCandy/Repositories/OrangeCandyRepository/を作成します。これがリポジトリインターフェイスになります。 OrangeCandyRepository.php

<?php
namespace RocketCandy\Repositories\OrangeCandyRepository;

interface OrangeCandyRepository {

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

    public function get_detail( $candy_id = 0 );

}

ログイン後にコピー

インターフェイスができたので、リポジトリを作成できます。

inapp/RocketCandy/Repositories/OrangeCandyRepository/を作成します。 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 ) {
        // 查询数据源并获取糖果详情
    }

}

ログイン後にコピー

リポジトリをCityAOrangeCandyRepositoryインターフェイスにバインドするには、LaravelのIOCコンテナを使用します。 OrangeCandyRepositoryを開き、ファイルの最後に次のことを追加します。 app/start/global.php

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

ログイン後にコピー

注：デモ用にIOCバインディングのみをに配置しました。理想的には、これらを独自のファイルに配置して、すべてのIOCバインディングを配置してからglobal.phpにこのファイルをロードするか、各IOCバインドを登録するサービスプロバイダーを作成できます。こちらをご覧ください。 global.php

インターフェイスを介してリポジトリを使用できます。

にあります。 app/controllers/

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

ログイン後にコピー

ここでは、OrangeCandyRepositoryインターフェイスをコントローラーに挿入し、オブジェクト参照をクラス変数に保存します。クラス変数は、コントローラーの任意の関数がデータを照会するために使用できるようになりました。 OrangeCandyRepositoryインターフェイスをCityAOrangeCandyRepositoryリポジトリにバインドするため、CityAOrangeCandyRepositoryリポジトリを直接使用するのとまったく同じです。

したがって、今、データソースのタイプとタイプはCityAOrangeCandyRepositoryの唯一の懸念です。当社のアプリケーションは、OrangeCandyRepositoryインターフェイスとその露出したAPIのみを知っており、それを実装する各リポジトリはそのAPIに準拠する必要があります。倉庫は、実行時にIOCコンテナから解析されます。つまり、インターフェイスは必要に応じて設定できますデータソースは、データベース、Webサービス、または次元間高ダタパイプラインになるようになりました。

すべてのケースが適用されるわけではありません リポジトリパターンの欠点で述べたように、アプリケーションにある程度の複雑さを追加します。したがって、小さなアプリケーションを作成していて、それが大きいところまで進化していない場合（複数のデータソースを呼び出す必要がある場合があります）、それを実装せず、古いスタイルのデータモデルに固執する方が良いです。何かを理解することは、いつ使用するかを知ることとは異なります。これは非常に便利な設計パターンであり、アプリケーションを作成するときやアプリケーションを維持または拡張（または削減）する必要があるときに多くのトラブルを節約しますが、すべてのアプリケーションの万能薬ではありません。

Laravel固有のコードを使用して上記の実装を実証しましたが、優れたIOCコンテナではかなり単純で類似しています。質問はありますか？以下のコメントでお知らせください。

脚注：