リポジトリパターンとストアドプロシージャ

Question

私は、リポジトリパターンとストアドプロシージャを使用するための良いプロジェクト例を探しています。私は何度も過ごしましたが、リポジトリのパターンとdbとの通信にspを使用する良い例は見つかりません。通常のCRUDでも、私はまだSPを使用します。

また、ストアドプロシージャの複雑なデータをEFでコード化する例はありますか？
たとえば、ストアドプロシージャは複数のデータテーブルを返しますか？ おかげ

Answer 1

私は リポジトリパターンでcommmunicateするためにSPを使用して任意の良い例を見つけることができません。通常のCRUDでも、私はまだSPを使用します。

patternとオプションについて考えてみましょう。あなたはSPのみを使用でき、オブジェクトはデータアクセスを担当します。サンプルプロジェクトは必要ありません。あなたは思うだけです。これはEntity永続クラスのCRUD操作のための基本的なインターフェイスである

public interface IEntityDao 
{ 
    IEnumerable<Entity> GetAll(); 
    Entity GetByKey(int key); 
    bool Insert(Entity data); 
    bool Update(Entity data); 
    bool Delete(int key); 
} 

：ストアドプロシージャでリポジトリを実装するとき

次のようなインタフェースで定義されたシンプルなDAO（データアクセスオブジェクト）で終了します。すべてのメソッド実装は、単一のストアドプロシージャを呼び出して操作を実行します。他の操作（フィルタリングや順序付けなど）が必要な場合は、新しいストアドプロシージャを作成し、このストアドプロシージャを呼び出す新しい操作を公開します。

これはリポジトリであるかどうか議論することができますが、単にSPはあなたに何も提供しません。たとえば、定義のこの部分は、一般的なレベルで達成することはほとんど不可能です：

クライアントは、宣言的クエリ仕様を構築し、満足のためにリポジトリに にそれらを提出するオブジェクト。

"クエリ仕様"は、常に特定のストアドプロシージャに固有のパラメータであり、公開された操作に渡されます。 SQLにパラメータとしてSQLを渡さない限り、クエリー全体を宣言的に定義することはできません。

ADO.NETでストアドプロシージャを直接呼び出すか、関数のインポートを使用するか、またはEFに関数/ExecuteStoreCommandを使用できます。 EFはこの制限を使用して複雑なストアドプロシージャを実行できます。

• ストアドプロシージャは単一の結果セットのみを返します。複数の結果セットの場合は、EFExtensionsが必要です。または、この機能を含める必要がある.NET 4.5を待つ必要があります
• ストアドプロシージャは異なる結果セットを返してはいけません。結果セットの構造はそれぞれ同じでなければなりませんSP実行（ピボットや動的SQLが異なる数の列を返す）

機能のインポートには、わずかな制限があります。これらのルールに従うと、SPが返すすべての結果セットに対してクラス/複合タイプを作成できます。