Entity Frameworkのみストアドプロシージャ

Question

このシナリオでは、ストアドプロシージャでのみエンティティフレームワークを使用することの合理性について質問があります。

UI、BusinessLayer（BLL）、DataAccessLayer（DAL）、およびBusinessObjectDefinitions（BOD）レイヤーを使用して、N層アーキテクチャーを計画しています。 BODレイヤーは他のすべてのレイヤーで認識されており、DALでの実行クエリの結果はBLLに渡される前にBODで定義されたオブジェクトに変換される必要があります。

すべてのCRUDメソッドに対してのみストアドプロシージャを使用します。 selectストアドプロシージャの場合は、関数importを追加して複合型を作成し、関数を実行するときに複合型の値をBODのクラスに変換してBLLに渡します。 基本的に、ビジネスオブジェクトに変換されるモデルにはエンティティはなく、複雑なタイプはありません。

私の意見では、私たちは多くの利益を失うので、それはすべて意味があるのか​​分かりません。

まったく間違っていますか？

Answer 1

私が使用していたものすべてがprocsを保存していた場合、私はEFを使用しません。

個人的に、私はPetaPocoのようなものを見てみたい、大規模あるいは単にストレートAdo.Net

EDIT

はここPetaPocoはのSPを消費し、カスタムタイプ

http://weblogs.asp.net/jalpeshpvadgama/archive/2011/06/20/petapoco-with-stored-procedures.aspxを出力する例です

Answer 2

すべてのCRUDメソッドでストアドプロシージャを使用する場合は、EFを使用する必要はありません。

Answer 3

私はここの既存の回答にはどちらも同意しません。 Petapocoは素晴らしいですが、EFはまだ多くの利点を提供していると思います。

Petapocoは、単一のエンティティまたはエンティティのリストを読み取る単純なストアドプロシージャを実行するのに優れています（おそらくEFより優れています）。しかし、一度データを読み込んで変更を開始する必要がある場合は、これがEFが明確な勝者であると感じています。手動で使用して挿入/更新ストアドプロシージャを呼び出す必要がありますpetapocoと/更新データを挿入するには

：

db.Execute("EXEC spName @param1 = 1, @param2 = 2") 

手動でストアドプロシージャ呼び出しを構築し、すべてのパラメータを宣言することは非常に速いときに、古い取得します挿入/更新ストアドプロシージャは、複数の列を持つ行を挿入します。これは、オプティミスティックな同時実行性を実装する更新ストアドプロシージャを呼び出すとき（すなわち、元の値をパラメータとして渡すとき）、さらに悪化する。

インラインストアドプロシージャ呼び出しで誤植をする可能性もあります。実行時までキャッチされない可能性があります。

今これをエンティティフレームワークと比較してください：EFでは、私のストアドプロシージャをedmxのエンティティにマップするだけです。エンティティ・フレームワーク・ツールは、ストアード・プロシージャーを分析してマッピングを自動的に生成するため、誤植のリスクは低くなります。

エンティティフレームワークも楽観的な並行性を問題なく処理します。それは私の変更を保存するには時間が来るとき最後に、唯一のステップで呼び出すことです：

entities.SaveChanges() 

Answer 4

私たちのDALとしてストアド・プロシージャ・コールをマップするためにEFを使用しています。関数をマッピングすることで、DALを書く時間を節約できます。 DBAは直接のデータ・テーブルへのアクセスを望まないため、LINQをSQLに使用していません。