Entity Framework と LINQ to SQL

https://stackoverflow.com/questions/8676

08-06-2019
|

質問

.NET v3.5 SP1 が (VS2008 SP1 とともに) リリースされたので、.NET エンティティフレームワークにアクセスできるようになりました。

私の質問はこれです。ORM として Entity Framework を使用するか LINQ to SQL を使用するかを決める場合、違いは何でしょうか?

私の理解では、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) は、オブジェクトドメインモデルとその多くの異なる ADO.Net データプロバイダーとの関係を広範に定義できる ORM (オブジェクトリレーショナルマッパー) API です。そのため、多数の異なるデータベースベンダー、アプリケーションサーバー、プロトコルを組み合わせて、さまざまなテーブル、ソース、サービスなどから構築されるオブジェクトの集約されたマッシュアップを設計できます。ADO.Net Framework は .Net Framework 3.5 SP1 とともにリリースされました。

これは MSDN の優れた紹介記事です。LINQ to リレーショナルデータの紹介

他のヒント

簡単で汚い答えは次のとおりだと思います

LINQ to SQL は、これをすばやく簡単に実行できる方法です。これは、小規模なものに取り組んでいる場合には、より早く作業を開始し、より早く納品できることを意味します。
Entity Framework は、これを実現するためのあらゆる手段を講じる手段です。これは、より大きなものに取り組んでいる場合には、事前により多くの時間を費やし、開発に時間がかかり、より柔軟に対応できることを意味します。

LINQ to SQL は本当に終わったのでしょうか? Jonathan Allen 著、InfoQ.com

マット・ウォーレンは、[Linqから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 は密接に結合されています - オブジェクトのプロパティとデータベースの特定のフィールド、より正確にはオブジェクトの特定のデータベーススキーマへのマッピング
L2S は (私の知る限り) SQL Server でのみ機能します
EF では、単一のクラスを複数のテーブルにマッピングできます
EF は M-M 関係を処理します
EF は、任意の ADO.NET データプロバイダーをターゲットにすることができます。

当初の前提では、L2S は迅速な開発用であり、EF はより「エンタープライズ」な n 層アプリケーション用であると考えられていましたが、それでは L2S が少し不足しています。

LINQ to SQL

同種のデータソース:SQLサーバー
データ構造が適切に設計されている小規模プロジェクトにのみ推奨されます
SqlMetal.exe を使用すると再コンパイルせずにマッピングを変更できます
.dbml (データベースマークアップ言語)
テーブルとクラス間の 1 対 1 マッピング
サポート TPH 継承
複合型はサポートされません
ストレージファーストのアプローチ
データベースのデータベース中心のビュー
C# チームによって作成されました
サポートされていますが、さらなる改善は意図されていません

エンティティフレームワーク

異種データソース: 多くのデータプロバイダーをサポート
以下を除くすべての新しいプロジェクトに推奨されます。
- 小さいもの (LINQ to SQL)
- データソースがフラットファイル（ADO.NET）の場合
モデルとマッピングファイルを設定するときに再コンパイルせずにマッピングを変更できる出力ディレクトリにコピーするメタデータアーティファクトプロセス
.edmx (Entity Data Model) には以下が含まれます。
- SSDL (ストレージスキーマ定義言語)
- CSDL (概念スキーマ定義言語)
- MSL (マッピング仕様言語)
テーブルとクラス間の 1 対 1、1 対多、多対 1 のマッピング
継承をサポートします。
- TPH (階層ごとのテーブル)
- TPT (タイプごとのテーブル)
- TPC (コンクリートクラスごとのテーブル)
複合型をサポート
コードファースト、モデルファースト、ストレージファーストのアプローチ
データベースのアプリケーション中心のビュー
SQL Server チームによって作成されました
Microsoft Data API の将来

以下も参照してください。

Entity Framework に関する私の経験は、あまり優れたものではありませんでした。まず、EF 基本クラスから継承する必要があるため、POCO には別れを告げます。デザインは EF 付近である必要があります。LinqtoSQL を使用すると、既存のビジネスオブジェクトを使用できます。さらに、遅延読み込みはないため、自分で実装する必要があります。POCO と遅延読み込みを使用するための回避策がいくつかありますが、EF がまだ準備ができていないため、それらは存在します。4.0以降に戻す予定です

とても良い答えを見つけましたここいつ何を使用するかを簡単な言葉で説明します。

使用するフレームワークの基本的な経験則は、プレゼンテーションレイヤーでデータの編集を計画する方法です。

リンクから SQL へ - プレゼンテーションレイヤーでデータの1対1の関係を編集する予定がある場合は、このフレームワークを使用してください。つまり、1つのビューまたはページに複数のテーブルからのデータを組み合わせる予定はありません。

エンティティフレームワーク - ビューまたはページの複数のテーブルからのデータを組み合わせることを計画している場合は、このフレームワークを使用してください。これを明確にするために、上記の用語は、表示されるだけでなく、ビューまたはページで操作されるデータに固有のものです。これは理解することが重要です。

エンティティフレームワークを使用すると、編集されたデータを「マージ」してプレゼンテーションレイヤーに編集可能なフォームに表示することができ、そのフォームが送信されると、EFはさまざまなテーブルのすべてのデータを更新する方法を知ることができます。

おそらく、L2よりもEFを選択するより正確な理由がありますが、これはおそらく最も簡単なものです。L2Sには、ビュープレゼンテーションのためにデータをマージする機能がありません。

私の印象では、Linq2Sql がニーズに合わない場合、データベースはかなり巨大であるか、非常に不適切な設計になっていると思われます。私には大小合わせて 10 個ほどの Web サイトがあり、すべて Linq2Sql を使用しています。Entity Framework を何度も調べましたが、Linq2Sql ではなく Entity Framework を使用する十分な理由が見つかりません。つまり、データベースをモデルとして使用しようとしているため、モデルとデータベースの間にはすでに 1 対 1 のマッピングが存在します。

私の現在の職場には、200 以上のテーブルを含むデータベースがあります。古いデータベースには不適切なソリューションがたくさんあるため、Linq2Sql よりも Entity Framework の利点がわかりますが、データベースはアプリケーションのエンジンであり、データベースの設計が悪く、アプリケーションが遅い場合は、データベースを再設計することを好みます。も遅くなります。このようなデータベースで Entity Framework を使用すると、悪いモデルを隠すための応急処置のように見えますが、そのようなデータベースから得られる悪いパフォーマンスを隠すことはできません。

ここで良い比較ができます。

http://www.dotnet-tricks.com/Tutorial/entityframework/1M5W300314-Difference-between-LINQ-to-SQL-and-Entity-Framework.html

http://www.c-sharpcorner.com/blogs/entity-framework-vs-linq-to-sql1

ここでの回答では、Linq2Sql と EF の違いの多くがカバーされていますが、あまり注目されていない重要な点があります。Linq2Sql は SQL Server のみをサポートしますが、EF には次の RDBMS のプロバイダーがあります。

マイクロソフト提供:

SQL Server、OBDC、および OLE DB 用の ADO.NET ドライバー

サードパーティプロバイダー経由:

MySQL
オラクル
DB2
VistaDB
SQLite
PostgreSQL
インフォミックス
U2
サイベース
シナジェックス
火の鳥
Npgsql

いくつか例を挙げると。

これにより、EF はリレーショナルデータストアに対する強力なプログラミング抽象化となり、開発者は基盤となるデータストアに関係なく、一貫したプログラミングモデルを使用できるようになります。これは、さまざまな一般的な RDBMS と確実に相互運用できる製品を開発している状況で非常に役立ちます。

この抽象化が役立つもう 1 つの状況は、さまざまな顧客や組織内のさまざまな事業単位と協力する開発チームの一員であり、必要な RDBMS の数を減らすことで開発者の生産性を向上させたい場合です。さまざまな RDBMS 上でさまざまなアプリケーションをサポートするために精通しています。

EF を使用する場合、同じデータベースモデル内で複数のデータベースを使用できないことがわかりました。しかし、linq2sql では、スキーマ名にデータベース名を接頭辞として付けるだけで済みます。

これが、私が最初に linq2sql を使い始めた理由の 1 つでした。EF がこの機能をまだ許可しているかどうかはわかりませんが、EF ではこれを許可しないように意図されていると読んだ記憶があります。

データベースが単純で単純であれば、LINQ to SQL で十分です。テーブルの上に論理/抽象エンティティが必要な場合は、Entity Framework を使用してください。

どちらもまだ、独自の SQL 2008 データ型をサポートしていません。私の観点からの違いは、Entity には将来のリリースで地理データ型に基づいてモデルを構築する機会がまだあり、Linq to SQL は放棄されたため、今後も構築されないということです。

nHibernate や OpenAccess はどうなっているのだろうか...

途中でおかしなことをせずに何かを迅速に開発する必要があり、テーブルを表すエンティティを持つ機能が必要な場合は、次のようになると思います。

Linq2Sql は優れた同盟国となり、LinQ と一緒に使用すると開発のタイミングが大幅に向上します。

私は、Linq-to-SQL を使用する大規模なプロジェクトを持つ顧客のために働いています。プロジェクトが開始されたとき、これは当然の選択でした。当時、Entity Framework にはいくつかの主要な機能が欠けており、Linq-to-SQL のパフォーマンスがはるかに優れていたからです。

現在、EF は進化しており、Linq-to-SQL には、拡張性の高いサービスに最適な非同期サポートがありません。時々 1 秒あたり 100 を超えるリクエストが発生し、データベースを最適化したにもかかわらず、ほとんどのクエリが完了するまでに依然として数ミリ秒かかります。同期データベース呼び出しのため、スレッドはブロックされ、他のリクエストには使用できません。

この機能のためだけに Entity Framework に切り替えることを検討しています。Microsoft が非同期サポートを Linq-to-SQL に実装しなかった (またはコミュニティが実装できるようにオープンソース化した) のは残念です。

2018 年 12 月追記: Microsoft は .NET Core に移行しており、Linq-2-SQL は .NET Core ではサポートされていないため、将来 EF.Core に確実に移行できるようにするには、EF に移行する必要があります。

他にも考慮すべきオプションがいくつかあります。 LLBLGen. 。これは、すでに長い間存在している成熟した ORM ソリューションであり、MS データソリューション (ODBC、ADO、ADO.NET、Linq-2-SQL、EF、EF.core) よりも将来性があることが証明されています。

LINQ to SQL と Entity Framework は、表面的には似ています。どちらも、データモデルを使用してデータベースに対してlinqクエリを提供します。

LINQからSQLは、LINQプロジェクトから進化しました。LINQプロジェクトは、言語開発に取り組むチームから出てきましたが、エンティティフレームワークはデータプログラマ性チームのプロジェクトであり、エンティティSQL言語に焦点を当てていました。Microsoft には、LINQ to SQL を非推奨にするつもりはまったくありません。

LINQ to SQL は依然として ADO.NET の一部ですが、Entity Framework には別個の API があります。Entity Framework は、LINQ to SQL の上位バージョンです。Entity Framework は、アプリケーションとデータストア間のブリッジに Entity Data Model を使用します。概念スキーマの定義と、データベースとの対話に必要なデータベーススキーマ情報、そして最終的に 2 つにリンクするマッピングスキーマを提供するのは、Entity Data Model (EDM) です。

Entity Framework (エンティティデータモデル) によって実行されるいくつかのタスクを次に示します。

•モデルからクラスを自動的に生成し、モデルが変更されるたびにこれらのクラスを動的に更新します。

• すべてのデータベース接続を処理するため、開発者はデータベースと対話するために大量のコードを作成する必要がなくなります。

• データベースではなくモデルをクエリするための共通のクエリ構文を提供し、これらのクエリをデータベースが理解できるクエリに変換します。

•モデルのオブジェクトがアプリケーションで使用されているため、モデルのオブジェクトを追跡するメカニズムを提供し、データベースの更新を処理します。

Linq-to-SQL

SQL Serverのみをサポートするプロバイダーです。これは、SQL Server データベーステーブルを .NET オブジェクトにマッピングするマッピングテクノロジです。ORM (オブジェクトリレーショナルマッパー) に対する Microsoft の最初の試みです。

エンティティへのリンク

同じアイデアですが、バックグラウンドで Entity Framework を ORM として使用します。これも Microsoft が提供するもので、複数のデータベースをサポートしています。エンティティフレームワークの主な利点は、開発者が任意のデータベースで作業できることです。異なるデータベースで操作を実行するための構文を学ぶ必要がありません。

私の個人的な経験によると、EFは（SQLについて知らない場合）Linqのパフォーマンスは、Lambdaで書かれたEF理由Linq言語と比較して少し速くなります。

ライセンス： CC-BY-SA と帰属

所属していません StackOverflow