.NET v3.5 SP1が（VS2008 SP1と共に）リリースされたので、.NETエンティティフレームワークにアクセスできるようになりました。
私の質問はこれです。EntityFrameworkとLINQtoSQLをORMとして使用するかどうかを決定しようとする場合、違いは何ですか？
私の理解では、Entity Framework（LINQ to Entitiesで使用する場合）は、LINQ to SQLの「兄貴」ですか？これが事実である場合-それはどのような利点がありますか？LINQ to SQLだけではできないことは何ができるでしょうか？
LINQ to SQL は、Microsoft SQL Server で使用可能なデータベース テーブル、ビュー、sproc、および関数の 1 対 1 のマッピングのみをサポートします。これは、比較的適切に設計された SQL Server データベースへの迅速なデータ アクセス構築に使用する優れた API です。LINQ2SQL は、C# 3.0 および .Net Framework 3.5 で最初にリリースされました。
LINQ to Entities (ADO.Net Entity Framework) は、ORM (Object Relational Mapper) API であり、オブジェクト ドメイン モデルの幅広い定義と、それらのさまざまな ADO.Net データ プロバイダーとの関係を可能にします。そのため、多数の異なるデータベース ベンダー、アプリケーション サーバー、またはプロトコルを組み合わせて、さまざまなテーブル、ソース、サービスなどから構築されたオブジェクトの集合マッシュアップを設計できます。ADO.Net Framework は、 .Net Framework 3.5 SP1。
これは MSDN の優れた入門記事です: LINQ とリレーショナル データの紹介
迅速で汚い答えはそれだと思います
LINQ to SQL は本当に死んでいますか? InfoQ.comのジョナサン・アレン著
Matt Warren は [LINQ to SQL] を「存在するはずがなかった」ものと表現しています。本質的には、実際の ORM の準備が整うまで、LINQ の開発を支援するための代役になるはずでした。
...
Entity Framework の規模が原因で、.NET 3.5/Visual Studio 2008 の期限に間に合いませんでした。これは、サービス パックというよりもメジャー リリースのような残念な名前の ".NET 3.5 Service Pack 1" に間に合うように完成しました。
...
開発者は [ADO.NET Entity Framework] を好まないのは、その複雑さのためです。
...
.NET 4.0 の時点で、LINQ to Entities は、LINQ to リレーショナル シナリオで推奨されるデータ アクセス ソリューションになります。
@larsが投稿した記事には明らかな違いがいくつかありますが、簡単な答えは次のとおりです。
当初の前提は、L2Sは迅速な開発用であり、EFはより「エンタープライズ」なn層アプリケーション用でしたが、それはL2Sを少し売りにしています。
以下も参照してください。
Entity Framework に関する私の経験は、素晴らしいものではありませんでした。まず、EF 基本クラスから継承する必要があるため、POCO に別れを告げます。あなたのデザインはEFの周りにある必要があります. LinqtoSQL を使用すると、既存のビジネス オブジェクトを使用できます。さらに、遅延読み込みはありません。自分で実装する必要があります。POCO と遅延読み込みを使用するためのいくつかの回避策がありますが、EF はまだ準備ができていないため、IMHO に存在します。4.0以降に戻す予定です
簡単な言葉で何をいつ使用するかを説明する非常に良い答えをここで見つけました：
どのフレームワークを使用するかの基本的な経験則は、プレゼンテーション層でデータを編集する方法を計画することです。
Linq-To-Sql - プレゼンテーション レイヤーでデータの 1 対 1 の関係を編集する予定がある場合は、このフレームワークを使用します。つまり、1 つのビューまたはページで複数のテーブルのデータを組み合わせる予定はありません。
Entity Framework - ビューまたはページで複数のテーブルのデータを結合する予定がある場合は、このフレームワークを使用します。これを明確にするために、上記の用語は、表示されるだけでなく、ビューまたはページで操作されるデータに固有のものです。これを理解することが重要です。
Entity Framework を使用すると、テーブル化されたデータをまとめて "マージ" して、編集可能なフォームでプレゼンテーション層に提示できます。その後、そのフォームが送信されると、EF はさまざまなテーブルからすべてのデータを更新する方法を認識します。
L2S よりも EF を選択するより正確な理由はおそらくありますが、おそらくこれが最も理解しやすいでしょう。L2S には、ビュー プレゼンテーション用にデータをマージする機能がありません。
私の印象では、Linq2Sql がニーズに合わない場合、データベースは非常に巨大であるか、設計が非常に悪いということです。私は、Linq2Sql を使用する大小の Web サイトを約 10 ほど持っています。私はエンティティ フレームワークを何度も見てきましたが、Linq2Sql でそれを使用する正当な理由が見つかりません。つまり、データベースをモデルとして使用しようとしているので、モデルとデータベースの間にはすでに 1 対 1 のマッピングがあります。
私の現在の仕事では、200 以上のテーブルを持つデータベースがあります。悪いソリューションがたくさんある古いデータベースなので、Linq2Sql よりも Entity Framework の利点を見ることができましたが、データベースはアプリケーションのエンジンであり、データベースの設計が不適切で遅い場合はアプリケーションを再設計することをお勧めします。も遅くなります。そのようなデータベースで Entity フレームワークを使用することは、悪いモデルを隠すための応急処置のように思えますが、そのようなデータベースから得られる悪いパフォーマンスを隠すことはできません。
ここでの回答は、Linq2Sql と EF の違いの多くをカバーしていますが、あまり注目されていない重要な点があります。Linq2Sql は SQL Server のみをサポートしているのに対し、EF は次の RDBMS のプロバイダーを持っています。
マイクロソフト提供:
サード パーティ プロバイダー経由:
いくつか挙げると。
これにより、EF はリレーショナル データ ストアに対する強力なプログラミングの抽象化になります。つまり、開発者は、基になるデータ ストアに関係なく、一貫したプログラミング モデルを使用できます。これは、幅広い一般的な RDBMS と相互運用できることを確認したい製品を開発している場合に非常に役立ちます。
この抽象化が役立つもう 1 つの状況は、多数のさまざまな顧客や組織内のさまざまなビジネス ユニットと連携する開発チームの一員であり、RDBMS の数を減らすことで開発者の生産性を向上させたい場合です。さまざまな RDBMS の上でさまざまなアプリケーションをサポートするために熟知しています。
EF を使用すると、同じデータベース モデル内で複数のデータベースを使用できないことがわかりました。しかし、linq2sql では、スキーマ名の前にデータベース名を付けるだけで済みました。
これが、私が最初に linq2sql を使い始めた理由の 1 つです。EF がまだこの機能を許可しているかどうかはわかりませんが、これを許可しないように意図されていたことを読んだことを覚えています。
データベースが簡単で単純な場合は、LINQ to SQL で十分です。テーブルの上に論理的/抽象化されたエンティティが必要な場合は、Entity Framework を使用してください。
どちらも、一意のSQL2008データ型をまだサポートしていません。私の観点からの違いは、エンティティは将来のリリースで地理データ型を中心にモデルを構築する機会がまだあり、Linq to SQLは放棄され、決してそうしないということです。
nHibernate、またはOpenAccessはどうなっているのだろうか...
途中に奇妙なものがなく、迅速に何かを開発する必要があり、テーブルを表すエンティティを持つ機能が必要な場合は、次のように思います。
Linq2Sqlは優れた味方になる可能性があり、LinQと一緒に使用すると、優れた開発タイミングが解き放たれます。
