Generic Repositoryには本当に利点がありますか？

新しいアプリ用の汎用リポジトリを作成する利点に関するいくつかの記事を読んでいました（例）。同じリポジトリを使用して、複数の異なるエンティティタイプに対して複数の処理を一度に実行できるため、このアイデアは素晴らしいようです。

IRepository repo = new EfRepository(); // Would normally pass through IOC into constructor 
var c1 = new Country() { Name = "United States", CountryCode = "US" };
var c2 = new Country() { Name = "Canada", CountryCode = "CA" };
var c3 = new Country() { Name = "Mexico", CountryCode = "MX" };
var p1 = new Province() { Country = c1, Name = "Alabama", Abbreviation = "AL" };
var p2 = new Province() { Country = c1, Name = "Alaska", Abbreviation = "AK" };
var p3 = new Province() { Country = c2, Name = "Alberta", Abbreviation = "AB" };
repo.Add<Country>(c1);
repo.Add<Country>(c2);
repo.Add<Country>(c3);
repo.Add<Province>(p1);
repo.Add<Province>(p2);
repo.Add<Province>(p3);
repo.Save();

ただし、リポジトリの残りの実装は、Linqに大きく依存しています。

IQueryable<T> Query();
IList<T> Find(Expression<Func<T,bool>> predicate);
T Get(Expression<Func<T,bool>> predicate);
T First(Expression<Func<T,bool>> predicate);
//... and so on

このリポジトリパターンはEntity Frameworkで非常に効果的であり、DbContext / DbSetで使用可能なメソッドの1対1マッピングを提供しました。しかし、Entity Framework以外のデータアクセステクノロジーに対するLinqの採用が遅いことを考えると、DbContextを直接操作することよりもどのような利点がありますか？

リポジトリのPetaPocoバージョンを作成しようとしましたが、PetaPocoはLinq式をサポートしていないため、基本的なGetAll、GetById、Add、Update、Delete、およびSaveにのみ使用しない限り、汎用IRepositoryインターフェイスの作成はほとんど役に立ちません。メソッドを作成し、基本クラスとして使用します。次に、以前に述語として渡すことができるすべての「where」節を処理するために、特殊なメソッドを使用して特定のリポジトリを作成する必要があります。

Generic Repositoryパターンは、Entity Framework以外の何かに役立ちますか？そうでない場合、Entity Frameworkを直接操作するのではなく、なぜ誰かがそれを使用するのでしょうか？

元のリンクは、サンプルコードで使用していたパターンを反映していません。こちらが（更新されたリンク）です。

一般的なリポジトリは、Entity Frameworkにとっても役に立たない（そして私見も悪い）。既に提供されているものIDbSet<T>（これは汎用リポジトリーです）に付加価値はありません。

既に説明したように、汎用リポジトリを他のデータアクセステクノロジの実装に置き換えることができるという議論は、独自のLinqプロバイダーの作成を要求する可能性があるため、かなり弱いです。

簡略化された単体テストに関する2番目の一般的な論点も間違っています。これは、モックリポジトリ/メモリ内データストレージで設定すると、Linqプロバイダーが別の機能を持つ別のプロバイダーに置き換えられるためです。Linq-to-entitiesプロバイダーは、Linq機能のサブセットのみをサポートしIQueryable<T>ます。インターフェイスで利用可能なすべてのメソッドをサポートするわけでもありません。データアクセスレイヤーとビジネスロジックレイヤー間で式ツリーを共有すると、データアクセスレイヤーの偽造を防止できます。クエリロジックを分離する必要があります。

強力な「汎用」抽象化が必要な場合は、他のパターンも含める必要があります。この場合、抽象クエリ言語を使用する必要があります。抽象言語は、リポジトリによって、使用されるデータアクセスレイヤーでサポートされている特定のクエリ言語に変換できます。これは、仕様パターンによって処理されます。Linq on IQueryableは仕様です（ただし、翻訳にはプロバイダー-または式ツリーをクエリに変換するカスタムビジターが必要です）が、独自の簡易バージョンを定義して使用できます。たとえば、NHibernateはCriteria APIを使用します。それでも最も簡単な方法は、特定の方法で特定のリポジトリを使用することです。この方法は、クエリロジックが抽象化の背後に完全に隠されて分離されているため、実装が最も簡単で、テストが最も簡単で、単体テストでの偽造が最も簡単です。

問題はリポジトリパターンではありません。データの取得と取得方法を抽象化するのは良いことです。

ここでの問題は実装です。任意の式がフィルタリングに機能すると仮定すると、せいぜい危険です。

すべてのオブジェクトに対してリポジトリを直接機能させることは、ポイントを逃します。データオブジェクトがビジネスオブジェクトに直接マップされることはほとんどありません。これらの状況では、Tをフィルターに渡すことはあまり意味がありません。そして、そのような多くの機能を提供することで、別のプロバイダーが登場すると、そのすべてをサポートすることができなくなります。

汎用データレイヤー（リポジトリは特定の種類のデータレイヤーです）の値により、呼び出し元のコードにほとんどまたはまったく影響を与えずに、コードが基になるストレージメカニズムを変更できます。

理論的には、これはうまく機能します。実際、あなたが観察したように、抽象化はしばしば漏れやすいものです。一方のデータにアクセスするために使用されるメカニズムは、もう一方のメカニズムとは異なります。場合によっては、ビジネスレイヤーで1回、データレイヤーでそれを繰り返すという2回のコードを書くことになります。

汎用データレイヤーを作成する最も効果的な方法は、アプリケーションが事前に使用するさまざまな種類のデータソースを知ることです。これまで見てきたように、LINQまたはSQLがユニバーサルであると仮定することは問題になる可能性があります。新しいデータストアを後付けしようとすると、書き換えが発生する可能性があります。

[編集：以下を追加しました。]

また、アプリケーションがデータ層から何を必要としているかにも依存します。アプリケーションがオブジェクトをロードまたは格納しているだけの場合、データレイヤーは非常に単純です。検索、並べ替え、フィルターの必要性が高まると、データレイヤーの複雑さが増し、抽象化が漏れやすくなります（問題のLINQクエリを公開するなど）。ただし、ユーザーが独自のクエリを提供できるようになったら、データレイヤーのコスト/メリットを慎重に検討する必要があります。

ほとんどの場合、データベースの上にコード層を置くことは価値があります。私は通常、上記のコードでは「GetByXXXXX」パターンを好むでしょう。UIをデータインターフェイスの乱雑さから解放しながら、必要に応じて背後のクエリを最適化できます。

ジェネリック医薬品を活用することは間違いなく公正なゲームLoad<T>(int id)です。メソッドを持つことは非常に理にかなっています。しかし、LINQの周りにリポジトリを構築することは、タイプセーフティを少し追加してSQLクエリをあらゆる場所にドロップするのと同じ2010年代のことです。

さて、提供されたリンクを使用すると、それがの便利なラッパーであることがわかりますが、DataServiceContextコード操作を減らしたり、可読性を改善したりすることはありません。また、へのアクセスDataServiceQuery<T>が妨げられ、柔軟性が.Where()とに制限されます.Single()。またAddRange()、代替手段も提供されていません。NORれるDelete(Predicate)有用である可能性が提供（repo.Delete<Person>( p => p.Name=="Joe" );ジョー-Sを削除します）。等。

結論：このようなAPIはネイティブAPIを妨害し、いくつかの単純な操作に制限します。

私は「はい」と言います。データモデルに応じて、よく開発された汎用リポジトリを使用すると、データアクセス層をよりスリムで洗練された、より堅牢なものにすることができます。

この一連の記事を読む（by @ chris-pratt）：

• 汎用エンティティ基本クラス
• 真に汎用的なリポジトリ、パート1
• 真に汎用的なリポジトリ、パート2