エンティティフレームワークVS LINQ to SQL VS ADO.NETとストアドプロシージャ [閉まっている]

それぞれについて、次の点でどのように評価しますか。

1. パフォーマンス
2. 開発のスピード
3. きちんとした、直感的な、保守可能なコード
4. 柔軟性
5. 全体

私は自分のSQLが好きなので、常にADO.NETとストアドプロシージャの熱心なファンでしたが、最近、Linq to SQLを試してみましたが、DataAccessレイヤーをすばやく書き出して費やすことに決めましたLinq to SQLまたはEFのどちらかを実際に理解している...どちらでもない？

私が確認したいのは、これらのテクノロジーのいずれにも、私の研究時間を無駄にするような大きな欠陥がないことです。たとえば、パフォーマンスはひどいです。シンプルなアプリにとってはクールですが、これまでのところしか利用できません。

更新： ORM VS SPではなくEF VS L2S VS SPに集中できますか？主にEF VS L2Sに興味があります。しかし、プレーンなSQlは私がよく知っているものなので、ストアドプロシージャと比較することにも熱心です。

まず、新しいプロジェクトを開始する場合は、Entity Framework（ "EF"）を使用します。これにより、より優れたSQL（Linq to SQLと同様）が生成され、Linq to SQL（ " L2S」）。.NET 4.0のリリースの時点では、Linq to SQLは時代遅れのテクノロジーであると考えています。MSは、L2S開発をこれ以上継続しないことについて非常にオープンです。

1）パフォーマンス

これは答えるのが難しいです。ほとんどの単一エンティティー操作（CRUD）では、3つのテクノロジーすべてでほぼ同等のパフォーマンスが得られます。EFとLinq to SQLを最大限に活用するには、それらがどのように機能するかを知っている必要があります。ポーリングクエリなどの大量の操作の場合、EF / L2Sでエンティティクエリを「コンパイル」して、フレームワークがSQLを常に再生成する必要がないようにするか、スケーラビリティの問題が発生する可能性があります。（編集を参照）

大量のデータを更新する一括更新の場合、生のSQLまたはストアドプロシージャは、ORMソリューションを介してデータをORMにマーシャリングする必要がないため、常にORMソリューションよりもパフォーマンスが高くなります。

2）開発のスピード

ほとんどのシナリオでは、EFは開発のスピードに関しては、裸のSQL /ストアドプロシージャを吹き飛ばします。EFデザイナは、変更に応じて（要求に応じて）データベースからモデルを更新できるため、オブジェクトコードとデータベースコードの間で同期の問題が発生することはありません。ORMの使用を検討しないのは、更新を行わないレポート/ダッシュボードタイプのアプリケーションを実行しているとき、またはデータベースで生データのメンテナンス操作を行うだけのアプリケーションを作成しているときだけです。

3）きちんとした/保守可能なコード

EFはSQL / sprocsに勝っています。関係はモデル化されているため、コード内の結合は比較的まれです。エンティティの関係は、ほとんどのクエリの読者にとってほぼ自明です。データに実際に何が起こっているのかを理解するために、層から層へのデバッグ、または複数のSQL /中間層を経由する必要があることほど悪いことはありません。EFは、非常に強力な方法でデータモデルをコードに取り込みます。

4）柔軟性

ストアドプロシージャとraw SQLはより「柔軟」です。sprocsとSQLを活用して、奇妙な特定のケースでより高速なクエリを生成できます。また、ORMを使用するよりも簡単にネイティブDB機能を活用できます。

5）全体

ストアドプロシージャを使用するのではなく、ORMを選択するという誤った二分法にとらわれないでください。 両方を同じアプリケーションで使用でき、おそらく使用する必要があります。大きな一括操作は、ストアドプロシージャまたはSQL（実際にはEFから呼び出すことができます）で行う必要があります。EFは、CRUD操作とほとんどの中間層のニーズに使用する必要があります。おそらく、レポートの作成にSQLを使用することを選択します。ストーリーのモラルはいつもと同じだと思います。ジョブに適したツールを使用します。しかし、その細い点は、EFが今日非常に優れていることです（.NET 4.0現在）。リアルタイムで読んで理解することで、驚くほど高性能なアプリを簡単に作成できます。

編集：EF 5は、自動コンパイルされたLINQクエリを使用してこの部分を少し簡略化しますが、実際の大量のものについては、実際に何が最適であるかをテストおよび分析する必要があります。

ストアドプロシージャ：

（+）

• 優れた柔軟性
• SQLの完全な制御
• 利用可能な最高のパフォーマンス

（-）

• SQLの知識が必要
• ストアドプロシージャはソース管理外です
• 同じテーブル名とフィールド名を指定している間、かなりの量の「繰り返し」。DBエンティティの名前を変更し、どこかにそれへの参照が不足していると、アプリケーションが破損する可能性が高くなります。
• 遅い開発

ORM：

（+）

• 急速な発展
• 現在ソース管理下にあるデータアクセスコード
• DBの変更から隔離されます。その場合は、モデル/マッピングを1か所で更新するだけで済みます。

（-）

• パフォーマンスが低下する可能性があります
• ORMが生成するSQLに対する制御がまったくないか、ほとんどない（非効率であるか、バグが多い可能性があります）。介入してカスタムストアドプロシージャに置き換える必要がある場合があります。これにより、コードが乱雑になります（コード内の一部のLINQ、コード内および/またはソース管理外のDB内の一部のSQL）。
• どんな抽象化でも、それが内部でどのように機能するかわからない「高レベル」の開発者を生み出すことができるので

一般的なトレードオフは、優れた柔軟性と多くの時間を失うことと、実行できることを制限されることと、非常に迅速に実行することの間のトレードオフです。

この質問に対する一般的な回答はありません。それは聖なる戦争の問題です。また、手元のプロジェクトとニーズにも依存します。自分に最適なものを選択してください。

あなたの質問は基本的にO / RMと手書きのSQLです

ORMまたはプレーンSQLを使用していますか？

他のO / RMソリューションのいくつかをご覧ください。L2Sだけがその1つではありません（NHibernate、ActiveRecord）

http://en.wikipedia.org/wiki/List_of_object-relational_mapping_software

特定の質問に対処するには：

1. O / RMソリューションの品質に応じて、L2SはSQLの生成にかなり優れています
2. これは通常、プロセスを実行するとO / RMを使用するとはるかに高速になります。
3. また、コードは通常、よりすっきりとしていて、保守しやすくなっています。
4. もちろん、ストレートSQLを使用すると柔軟性が高まりますが、ほとんどのO / RMは、最も複雑なクエリを除くすべてを実行できます
5. 全体的に、O / RMを使用することをお勧めします。柔軟性の損失はごくわずかです

LINQ-to-SQLは、非常に使いやすく、概してバックエンドへの非常に優れたクエリを生成する、注目に値するテクノロジです。LINQ-to-EFはこれに取って代わる予定でしたが、歴史的に使用するのは非常に不格好であり、はるかに劣ったSQLを生成していました。私は現在の状況を知りませんが、マイクロソフトはL2Sのすべての優れた点をL2EFに移行することを約束しました。

個人的に、私はORMツールに情熱を抱いて嫌いです（詳細については、ここの私のダイアトリブを参照してください）。したがって、L2Sはデータアクセスレイヤーから必要とするすべてのことを期待するので、L2EFを支持する理由はありません。実際、手作りのマッピングや継承モデリングなどのL2S機能は、完全に不必要な複雑さを追加すると思います。しかし、それは私だけです。;-)

ストアドプロシージャの能力とパフォーマンス、およびEntity Frameworkのようなツールが提供する迅速な開発である場合は、まったく新しいアプローチを検討する必要があります。

小規模なプロジェクトのテストドライブとしてSQL +を使用しましたが、それは本当に特別なものです。基本的にコメントに相当するものをSQLルーチンに追加し、それらのコメントはコードジェネレーターに指示を提供します。コードジェネレーターは、実際のSQLルーチンに基づいて非常に優れたオブジェクト指向クラスライブラリを構築します。逆のようなエンティティフレームワークのようなもの。

入力パラメーターは入力オブジェクトの一部になり、出力パラメーターと結果セットは出力オブジェクトの一部になり、サービスコンポーネントはメソッド呼び出しを提供します。

ストアドプロシージャを使用したいが、それでも迅速な開発が必要な場合は、この内容を確認することをお勧めします。