.net - 違い - Entity FrameworkとLINQ to SQL




linq to entities (11)

Linq-to-SQL

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

Linq-to-Entities

同じ考えですが、ORMとしてバックグラウンドでEntity Frameworkを使用します-再びMicrosoftが提供する、複数のデータベースをサポートするエンティティフレームワークの主な利点は、異なるデータベースで操作を実行するための構文を学習する必要のないデータベースで作業できることです

私の個人的な経験によれば、Efの方が優れています(SQLの知識がなければ)LINQのパフォーマンスは、ラムダで記述されたEFの理由LINQ言語に比べて少し高速です。

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

私の質問はこれです。 Entity FrameworkとLINQ to SQLのどちらをORMとして使用するかを決定しようとすると、違いは何ですか?

私が理解しているように、Entity Framework(LINQ to Entitiesで使用する場合)はLINQ to SQLの「兄弟」ですか? この場合、どのような利点がありますか? LINQ to SQLが単独ではできないことは何ができますか?


LINQ to SQL

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

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

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

こちらもご覧ください:


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

これが、私が当初linq2sqlで作業を始めた理由の1つです。 EFがこの機能をまだ許可しているかどうかはわかりませんが、これを許可しないことを意図していたことを読んだことを覚えています。


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


hereでは、簡単な言葉で何を使用するかを説明する非常に良い答えを見つけました:

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

  • Linq-To-Sql-プレゼンテーションレイヤーのデータの1対1の関係を編集する予定がある場合は、このフレームワークを使用します。 つまり、1つのビューまたはページで複数のテーブルのデータを結合する予定はありません。

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

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

おそらく、L2SよりもEFを選択するより正確な理由がありますが、これはおそらく最も理解しやすいものでしょう。 L2Sには、ビューを表示するためにデータをマージする機能がありません。


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リレーショナルシナリオの推奨データアクセスソリューションになります。


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

マイクロソフト提供:

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

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

  • MySQL
  • オラクル
  • DB2
  • VistaDB
  • SQLite
  • PostgreSQL
  • Informix
  • U2
  • Sybase
  • Synergex
  • 火の鳥
  • Npgsql

いくつか例を挙げます。

これにより、EFはリレーショナルデータストアに対する強力なプログラミング抽象化となり、開発者は基礎となるデータストアに関係なく動作する一貫したプログラミングモデルを使用できます。 これは、幅広い一般的なRDBMSと相互運用できることを保証したい製品を開発している場合に非常に便利です。

その抽象化が役立つもう1つの状況は、あなたが多くの異なる顧客、または組織内の異なるビジネスユニットと連携する開発チームの一員であり、RDBMSの数を減らして開発者の生産性を向上させたい場合です。さまざまなRDBMS上でさまざまなアプリケーションをサポートするために精通しています。


どちらもまだ一意のSQL 2008データ型をサポートしていません。 私の観点との違いは、将来のリリースでエンティティが私の地理データ型の周りにモデルを構築する機会をまだ持っており、Linq to SQLが放棄されることは決してないということです。

nHibernateまたはOpenAccessの最新情報を知りたい...


早くて汚い答えは

  • LINQ to SQLは、それを行うための迅速で簡単な方法です。 これは、あなたがより速く行くことを意味します、そしてあなたがより小さい何かに取り組んでいるならば、より速く配達します。
  • Entity Frameworkは、それを実行するための全面的で無制限の方法です。 これは、より大きなものに取り組んでいる場合、より多くの時間を前もって準備し、開発を遅くし、柔軟性を高めることを意味します。

私の印象では、Linq2Sqlがニーズに合わない場合、データベースは非常に膨大であるか、非常に不適切に設計されています。 私は、Linq2Sqlを使用して、大小両方のWebサイトを約10個持っています。 私は何度もEntityフレームワークを見てきましたが、Linq2Sqlで使用する正当な理由を見つけることができません。 データベースをモデルとして使用しようとしているので、モデルとデータベースの間にはすでに1対1のマッピングがあります。

現在の仕事では、200以上のテーブルを持つデータベースがあります。 古いデータベースには多くの悪い解決策があるので、Linq2SqlよりもEntity Frameworkの利点を見ることができますが、データベースはアプリケーションのエンジンであり、データベースがうまく設計されておらず、アプリケーションが遅い場合はデータベースを再設計することをお勧めしますまた遅くなります。 このようなデータベースでEntityフレームワークを使用することは、悪いモデルを隠すためのクイックフィックスのように思えますが、そのようなデータベースから得られる悪いパフォーマンスを隠すことはできません。


途中で奇妙なことをせずに何かを迅速に開発する必要があり、テーブルを表すエンティティを持つ機能が必要だと思います:

Linq2Sqlは、LinQで使用することにより、優れた開発タイミングを実現できます。





linq-to-sql