リポジトリパターンの段階的な説明[終了]

276

誰かが私に.NETのリポジトリパターンを説明してくれますか？

これは非常に一般的な質問であることは知っていますが、これまでのところ、満足のいく答えが見つかりません。

c# asp.net design-patterns repository

— サパティル
ソース

msdn.microsoft.com/en-us/library/ff649690.aspxとcodeproject.com/Tips/309753/...

— マールテン

ここに良い記事があります：deviq.com/repository-pattern

— ssmith

回答:

199

まとめとして、リポジトリパターンのより広範な影響について説明します。これにより、オブジェクトがどのように永続化されるかを知らなくても、すべてのコードでオブジェクトを使用できます。テーブルからオブジェクトへのマッピングを含む、永続性に関するすべての知識は、リポジトリに安全に含まれています。

コードベースにSQLクエリが散在していることがよくあります。テーブルに列を追加する場合は、コードファイルを検索してテーブルの使用方法を見つけなければなりません。変更の影響は広範囲に及びます。

リポジトリパターンを使用すると、1つのオブジェクトと1つのリポジトリを変更するだけで済みます。影響は非常に小さいです。

おそらく、リポジトリパターンを使用する理由を考えると役立つでしょう。ここにいくつかの理由があります：

データアクセスを変更できる場所は1か所だけ
テーブルのセットを担当する場所は1つだけです（通常）。
リポジトリをテスト用の偽の実装に置き換えるのは簡単です。そのため、単体テストで使用できるデータベースを用意する必要はありません。

たとえば、MySQLを使用していて、SQL Serverに切り替えたい場合など、他にもメリットがありますが、実際にこれを見たことはありません。

— フェントン
ソース

REをdbms aからbに切り替えて、これを見たことがあるだけでなく、プロダクションコードでこれを行ったことを記録します。以前はOracleを使用していたため、ホスティングプロバイダーを切り替え、Azureで（Oracleをサポートする前に）解決する必要があったため、SQL Azureに変換する必要がありました。残念ながら、その時点ではすべてのデータアクセスロジックを分離していませんでしたが、その移行を行ったように確実に分離しました（今後、追加する可能性があります）。

— Joe、

私はこのコメントが古く、トピック外としてクローズされていることを知っていますが、これは複数の会社で行われたのを見てきました。通常、これはORMに向かう、またはORMから離れるプロセスの一部です。リポジトリを使用すると、特に抽象ファクトリパターンからロードする場合やIoCコンテナを使用する場合に、リポジトリを簡単に切り替えることができます。

— Derek Van Cuyk

実際、リポジトリはデータソース関連の操作にDAOを使用しています...

— Yousha Aleayoub

@YoushaAleayoubあなたが提起する良い点。通常、データアクセスオブジェクトは、「データベースを分離」しようとするときに見つかり、リポジトリが「クエリに対して1つのものを作成」しようとするときに見つかります。ほとんどの場合、両方が一緒に見つかります。DAOの部分がありIConnection、ICommandデータベースの種類を隠しなど一部。リポジトリは通常、ドメイン中心です。

— フェントン

181

これは良い例です：C＃のリポジトリパターンの例

基本的に、リポジトリーは、データがデータベースからフェッチされたり、データベースに永続化されたりする詳細を非表示にします。カバーの下に：

読み取りの場合、指定された基準を満たすクエリを作成し、結果セットを返します
書き込みのために、基盤となる永続化エンジン（SQLデータベースなど）にデータを保存させるために必要なコマンドを発行します

— Twoflower
ソース

この例はこれまでで最も良い説明であり、MSDNドキュメントよりも優れています。

— Teoman Shipahi 2014

私はこれがとても良いと思いました。また、作業ユニットについての適切な説明も提供します。これは、リポジトリパターンよりもデータパターンのより一般的な形式のようです

— Celdor

リンクされた例は、リポジトリパターンの失敗です。Entity Framework（IDbContext）またはnhibernate（ISession）で直接提供されるインターフェースを使用する場合と比較して、まったく利点がありません。正しく実装されたリポジトリは、すべての永続性固有の情報（現在のLinq To Sqlプロバイダーの動作など）を抽象化します。つまり、決して公開しないでくださいIQueryable。

— jgauffin

@jgauffin IQueryableは永続性固有の情報ではありません。IQueryableのバッキングは、ハードコードされた配列のように単純な場合もあれば、XMLファイル、Webサービス、データベース、フラットファイルなどからの場合もあります。常にIQueryableを公開しないリポジトリはお勧めしません。すべてのケースでデータアクセスが遅くなります。IQueryableを公開すると、永続ストアにその機能がある場合、一部のインスタンスでパフォーマンスの拡張を実行できるようになります。さらに、DbContextを非表示にすると、必要に応じて（またはORMなしで）別のORMに切り替えることができます

— Robert McKee

永続化情報固有の情報を漏らします。IN特定のLinqToSqlプロバイダーがそれをどのように行うかを知らずに、eager / lazyロードを使用するか、SQL句を構築してみてください。

— jgauffin