0

MVCアプリを「アップグレード」しています。以前は、DALは、標準のLINQ to SQLクエリを使用する一連のリポジトリ（エンティティ名に基づく）として、モデルの一部でした。現在、これは別のプロジェクトであり、PLINQOを使用して生成されます。

PLINQOはエンティティのプロパティに基づいてクエリ拡張機能を生成するため、コントローラーで直接使用し始めました...そしてリポジトリをすべて削除しました。

正常に動作しています。これはあなたの経験に基づいた質問です。このパスを続行する必要がありますか、それともリポジトリを再構築する必要がありますか（リポジトリファイル内のDALとしてPLINQOを使用）？

PLINQOで生成されたデータコンテキストを使用する利点の1つは、DBアクセスが必要な場合に、データコンテキストへの参照を1つだけ作成することです。リポジトリパターンでは、データアクセスが必要なときに各リポジトリを参照する必要があり、単一のコントローラー上の複数のリポジトリを参照する必要がある場合もありました。

私がリポジトリで見た大きな利点は、適切な名前のクエリメソッド（つまり、FindAllProductsByCategoryId（int id）など）でした。PLINQOコードでは、それは_db.Product.ByCatId（int id）です-これも悪くはありません。

私は両方が好きですが、それが「ハリアー」になるのは、クエリが述語を使用する場合です。それをリポジトリクエリメソッドにロールアップできます。ただし、PLINQOコードでは、_db.Product.Where（x => x.CatId == 1 && x.OrderId == 1）;のようになります。コントローラーにそのようなコードを含めるのが好きかどうかはわかりません。

これについてどう思いますか？

4

1 に答える 1

2

-クエリ拡張機能-

PLINQOのクエリ拡張機能は、連鎖可能になるように設計されています。これは、物事が「ハリー」になりすぎないようにするのに役立つはずです。;）

// Lambda
_db.Product.Where（x => x.CatId == 1 && x.OrderId == 1）;
//拡張機能をクエリ
します_db.Product.ByCatId（1）.ByOrderId（1）;

//さらに複雑な
Lambda_db.Product.Where（x =>（x.CatId == 1 || x.CatId == 3）&& x.OrderId！= 1）;
//クエリ拡張機能
_db.Product.ByCatId（1、3）.ByOrderId（ComparisonOperator.NotEqual、1）;

また、非常に複雑なクエリの場合は、編集可能な（パッシブに生成された）クエリ拡張ファイルにカスタム拡張メソッドを追加することをお勧めします。これにより、より高度なロジックを1つの場所にカプセル化し、コードをよりクリーンで高度なロジックの再利用性を維持できます。

http://docs.codesmithtools.com/display/PLINQO/Query+Extensions

- パターン -

パターンに関しては、通常、DBにアクセスするたびにusingステートメントでDataContextを更新することをお勧めします。LINQ to SQL（したがってPLINQO）は、作業単位パターンを使用しており、小さな制御されたスコープで適切に機能するように設計されています。

于 2010-06-16T16:54:30.690 に答える