ストアドプロシージャを使用したEntity Framework VS LINQ to SQL VS ADO.NET
あなたはどのようにあなたはそれらのそれぞれについて次の点で評価しますか？
- パフォーマンス
- 開発スピード
- きちんとした、直感的で保守可能なコード
- 柔軟性
- 全体
私は自分のSQLが好きで、常にADO.NETとストアドプロシージャを熱望していましたが、最近Linq to SQLでプレイしていて、DataAccessレイヤをすばやく書き出して費やすことに決めたSQLやEFへのLinqのどちらかを本当に理解している時間があるかもしれません。
私の研究時間を無駄にするようなこれらの技術のどれにも大きな欠陥がないことを確認したいだけです。例えば。パフォーマンスはひどいです、それはシンプルなアプリのためにクールですが、これまでのところあなたを取ることができるだけです。
更新：ORM VS SPではなくEF VS L2S VS SPに集中できますか。私は主にEF VS L2Sに興味があります。しかし、普通のSQlは私がよく知っているものなので、それらをストアドプロシージャと比較してもらいたいです。
まず最初に、新しいプロジェクトを始めるのであれば、Entity Framework（ "EF"）を使ってください。Linqto SQLよりもはるかに優れたSQLを生成でき、保守も簡単で強力です（ " L2S "）。 .NET 4.0のリリース時点では、Linq to SQLは時代遅れのテクノロジだと思います。 MSは、L2Sの開発をこれ以上進めないことについて非常にオープンになっています。
1）公演
これは答えるのが難しいです。ほとんどの単一エンティティ操作（ CRUD ）では、3つのテクノロジすべてで同等のパフォーマンスが得られます。 EFとLinq to SQLを最大限に活用するには、それらがどのように機能するのかを知っておく必要があります。ポーリングクエリのような大量の操作の場合は、フレームワークが常にSQLを再生成する必要がないようにEF/L2Sにエンティティクエリを「コンパイル」させたり、スケーラビリティの問題に遭遇することができます。 （編集を参照）
大量のデータを更新する一括更新では、更新を実行するためにデータをORMに転送する必要がないため、生のSQLまたはストアドプロシージャは常にORMソリューションよりも優れたパフォーマンスを発揮します。
2）開発スピード
ほとんどのシナリオでは、EFは開発速度の面で裸のSQL /ストアドプロシージャを破壊します。 EF設計者は、（要求に応じて）モデルが変更されたときにデータベースからモデルを更新できるため、オブジェクトコードとデータベースコードの間で同期の問題に遭遇することはありません。 ORMの使用を検討しないのは、更新を行わないレポート作成/ダッシュボードタイプのアプリケーションを実行しているとき、またはデータベースに対して生データのメンテナンス操作を実行するためだけのアプリケーションを作成しているときだけです。
3）きちんとした/保守可能なコード
手を伸ばして、EFはSQL/sprocsを破った。あなたの関係はモデル化されているので、あなたのコードの中の結合は比較的まれです。エンティティの関係は、ほとんどのクエリに対して読者にはほとんど自明のことです。実際にデータに何が起きているのかを理解するために、階層ごとのデバッグや、複数のSQL /中間層を経由する必要がある以上に悪いことはありません。 EFは非常に強力な方法であなたのデータモデルをあなたのコードに取り入れます。
4）柔軟性
ストアドプロシージャと生のSQLはより "柔軟"です。 sprocsとSQLを利用して、奇妙な特定のケースに対してより高速なクエリを生成できます。また、ORMを使用するよりも簡単にネイティブDB機能を利用できます。
5）全体
ストアドプロシージャを使用してORMを選択するという誤った二分法に巻き込まれないでください。両方を同じアプリケーションで使用できますが、おそらくそうするべきです。大きな一括操作はストアドプロシージャまたはSQL（実際にはEFから呼び出すことができます）で行い、EFはCRUD操作と中間層のほとんどのニーズに使用する必要があります。おそらくあなたはあなたのレポートを書くためにSQLを使うことを選ぶでしょう。私は物語の道徳はそれが常にされているのと同じであると思います。仕事に適したツールを使用してください。しかし、その細かいところでは、EFは最近非常に優れています（.NET 4.0以降）。リアルタイムで読んで理解することで、驚くべき高性能のアプリを簡単に作成できます。
EDIT：EF 5はこの部分を 自動コンパイルされたLINQクエリ で少し簡略化しますが、実際の大容量のものは、実社会であなたに最適なものをテストして分析する必要があります。
ストアドプロシージャ：
（++）
- 優れた柔軟性
- SQLを完全に制御
- 利用可能な最高のパフォーマンス
（ - ）
- SQLの知識が必要
- ストアドプロシージャがソース管理外
- 同じテーブル名とフィールド名を指定しながら、かなりの量の "自分自身を繰り返す"。 DBエンティティの名前を変更した後、どこかでそれを参照していないためにアプリケーションが壊れる可能性が高い。
- 遅い開発
ORM：
（+）
- 急速な発展
- 現在ソース管理下にあるデータアクセスコード
- あなたはDBの変更から隔離されています。その場合は、モデル/マッピングを一箇所で更新するだけで済みます。
（ - ）
- パフォーマンスが悪くなる可能性があります
- ORMが生成するSQLをまったく制御できないか、ほとんど制御できません（非効率的またはより悪いバグになる可能性があります）。介入してカスタムストアドプロシージャに置き換える必要があるかもしれません。それはあなたのコードを面倒にするでしょう（あるコードはLINQ、あるコードはSQLそして/またはDBはソース管理不能）。
- どんな抽象化でもそれが内部でどのように機能するのかわからない「高レベル」の開発者を生み出すことができるので
一般的なトレードオフは、大きな柔軟性を持つことと多くの時間を浪費することと、できることに制限があることの間ではあるが非常に迅速にそれを行うこととの間にあります。
この質問に対する一般的な答えはありません。それは聖戦の問題です。手元のプロジェクトとあなたのニーズにもよります。あなたに最適なものを選びましょう。
あなたの質問は基本的にO/RM対SQLの手書き
他のO/RMソリューションのいくつかをご覧ください。L2Sだけが唯一のものではありません（NHibernate、ActiveRecord）。
http://en.wikipedia.org/wiki/List_of_object-relational_mapping_software
具体的な質問に対処するには：
- O/RMソリューションの品質にもよりますが、L2SはSQL生成にかなり優れています。
- プロセスを調べた後は、通常これはO/RMを使用する方がはるかに高速です。
- コードは通常、はるかに洗練されており、保守も容易です。
- ストレートSQLはもちろんより柔軟になりますが、ほとんどのO/RMは最も複雑なクエリを除くすべてを実行できます。
- 全体的に私はO/RMで行くことをお勧めします、柔軟性の損失は無視できる
LINQ-to-SQLは非常に簡単に使用できる驚くべき技術であり、概してバックエンドに対して非常に優れたクエリを生成します。 LINQ-to-EFはそれに取って代わると考えられていましたが、歴史的に使用するのが非常に扱いにくく、はるかに劣ったSQLを生成しました。私は現在の状況を知りませんが、マイクロソフトはL2Sの長所をすべてL2EFに移行することを約束しました。
個人的には、私はORMツールに熱心に嫌いです（詳細については私のdiatribe こちら を見てください）、そしてL2SからL2EFを支持する理由はありません私が今まで必要としてきたことはすべてデータアクセス層から得てくれます。実際、手作りのマッピングや継承モデリングなどのL2S機能によって、まったく不要な複雑さが増すとさえ思います。しかし、それは私だけです。 ;-)
ストアドプロシージャの能力とパフォーマンス、そしてEntity Frameworkのようなツールが提供する迅速な開発であるかどうかを検討する必要があるかもしれない、まったく新しいアプローチがあります。
私は小さなプロジェクトでテストドライブするためにSQL +を取った、そしてそれは本当に特別な何かである。あなたは基本的にあなたのSQLルーチンにコメントに相当する量を追加します、そしてそれらのコメントは実際のSQLルーチンに基づいて本当にいいオブジェクト指向クラスライブラリを構築するコードジェネレータに命令を提供します。逆のような種類のエンティティフレームワーク。
入力パラメータは入力オブジェクトの一部となり、出力パラメータと結果セットは出力オブジェクトの一部となり、サービスコンポーネントはメソッド呼び出しを提供します。
ストアドプロシージャを使用したいが、それでも迅速な開発が必要な場合は、この点を検討してください。