10

LinqToSqlと比較して、Entity Frameworkはやり過ぎであるか、習得が難しいと言われていると聞きました。

私はどのように疑問に思っていますか？私はLinqToSqlを使用し、それが好きです。ですから、私はEFを試していますが、私が行っていることについては、ほとんど同じように見えます。名前空間とメソッド名は異なりますが、これまでのところ、EFをLinqToSqlよりも難しくするものは見当たりません。

もっと複雑なことを始めれば、もっと複雑になると思います。しかし、繰り返しになりますが、LinqToSqlで同じことを行うことはおそらくまったくできないので、もっと複雑なことをしたい場合に備えて、EFのプラスとしてそれを見ることができます。

EFはLinqToSqlよりも多くのリソースを使用するので、必要なのがLinqToSqlのような機能だけである場合は使用しないでください。

更新：いくつかのテストを実行しましたが、テストでは、LinqtoSQLよりもパフォーマンスが優れているLinqtoEntitiesを示しているようです。

最初に1つのテーブルから1000レコードを削除し、1000レコードを追加し、1000レコードを編集してから、それらをDataViewにデータバインドします。LinqToSQL：5秒LinqToEntities：2秒

2つの結合されたテーブルを使用して同じテストを実行しましたが、結果は類似していました。

私のテストは別の投稿をサポートしているようです： LinqToSqlとEntityFrameworkのパフォーマンス

アップデート2：

返信ありがとうございます。Linq to Entitiesは、LinqtoSQLと比べて実際にはやり過ぎではないように思われます。さらに調査した後、LinqtoEntitiesを使用するのが道だと思います。パフォーマンスが優れているようです。

私が聞いた「やり過ぎ」のステートメントは、LinqtoEntitiesがLinqToSQLよりもはるかに多くのことを実行でき、より多くの構成（web.configに約1行追加）が必要なために行われたと思います。また、Linq toEntitiesがLinqtoSQLとは異なる方法で行う小さなことがあり、LinqtoEntitiesがより複雑であるかのように感じる可能性があります。しかし、物事を行う方法を学んだら、LinqtoEntitiesはLinqtoSQLほど複雑ではないようです。

4

6 に答える 6

12

間違っている場合は訂正してください。ただし、エンティティ フレームワークは、異なるデータ ソースのテーブルを結合したり、テーブルを分割したりする場合など、バックエンド オブジェクトを変換する必要がある場合にのみ機能する必要があります。エンティティ レイヤーが追加されます。そのため、すべての配管を非表示にして、クリーンアップされたエンティティのみを処理できます。LINQ to SQL の場合のように、テーブルに対して 1 対 1 で使用するだけの場合、使用していない複雑なレイヤーによって速度が低下することは間違いありません。より複雑なデータ ソースが必要になるまでは、LINQ to SQL が適切なジョブに適したツールであるように思えます。

于 2008-11-07T16:00:42.983 に答える
8

Linq to SQL と Entity Framework は概念的に異なる獣であり、マイクロベンチマークではなく、ニーズにどのように適合するかに基づいて選択する必要があります。Entity Framework の方が遅かったとしても、Microsoft の ADO.NET チームの焦点であり、何度も改善される予定です。Linq-to-SQL は効果的に凍結されています。

概念的には、Linq-to-SQL は Linq を使用してデータベース クエリを実行する方法にすぎないという点で異なります。当たり前のことのように聞こえますが、要点は次のとおりです。データのデータベース モデルに従って構造化されたデータにアクセスしているということです。FK は適切に変換されますが、データが別のテーブルに正規化された余分なオブジェクトがまだ残っています。作成するすべてのクエリは、そのようなことに対処する必要があります。

Entity Framework を使用すると、メモリ内でデータを表現する方法でデータを表現するレイヤーを宣言的に構築し、複数のテーブルのデータを適切な単一のオブジェクトに取り込むことができます。多対多の関係をコレクション プロパティなどとして表現します。その後、作成するクエリはこのモデルに対して行われ、目的がより明確で明確になります (15 個のテーブル結合はもうありません!)。

O'Reilly は、2009 年 1 月 15 日に Entity Framework に関する包括的な本を出版しています (プレビューは現在、Roughcuts で入手可能です)。Entity Framework の使用に自信がない場合は、現時点で MSDN のドキュメントがほとんど役に立たないため、提案がさらに難しくなっています。 . 私は、最も些細なプロジェクトを除いて、長期的にはそれを使用する価値があると信じています (個人的に、些細なことを書いている場合は、ADO.NET2 を直接使用し、Linq のことは忘れます)。

于 2008-12-30T00:33:42.553 に答える
5

ただし、グループ化などでクエリを使用する場合、LinqToEntities は非常に興味深いことを実行できることに注意してください。LinqToEntities を取得して group by を実際の SQL group by に変換することはできませんでした。代わりに、実際には効果のない大量のコード ブロックが生成されます。

たとえば、次のリンクを確認してください: http://social.msdn.microsoft.com/Forums/en-US/adodotnetentityframework/thread/bb72fae4-0709-48f2-8f85-31d0b6a85f68

「重要な」クエリを作成しようとする場合、ObjectQuery.ToTraceString() は、EF が背後で本当に愚かなことをしないようにするための親友です。

于 2010-02-16T10:16:15.973 に答える
3

私の答え: 単純な Get/Edit/Update シーケンスを実行するのにかかった時間を簡単に比較してください。LINQ to SQL は 2 倍高速であることがわかると思います。違いを調査していたときに、簡単な比較プロジェクトを行いました。
結果: Entity Framework 8,700 ミリ秒 LINQ to SQL 3,100 ミリ秒 データセット 2,000 ミリ秒

だから私にとっては簡単な質問でした。DataSets を使用するか、Linq-Sql を使用します - Entity Framework はそれを考慮しませんでした!

リンクテキスト

于 2008-11-06T01:17:32.733 に答える
3

Linq To SQL に飛び込む前に、プログラム マネージャーによるこの記事をチェックしてください。彼は、「LINQ to SQL は死んだのか?」という率直な質問を投げかけます。答えは簡単ではありません。それは決して「いいえ」ではありません。私には「おそらく多分」のように聞こえます。

EF (現在は Linq To Entities と呼ばれています) に飛び込む前に、NHibernate を真剣に検討することをお勧めしますが、それは私の個人的な偏見です。

于 2008-11-07T16:16:39.783 に答える
2

SqlDataReader を使用して通常の SQL クエリを実行し、それらを Generic List にバインドしないでください。SQL は、どの ORM よりもはるかに柔軟で強力なようです。とにかく実践！！SQLは死んでいますか？そして、それは最速のアプローチでなければならず、欠点はSQL文字列ですが、金属に近いところで作業しているため、ORMを使用するよりもはるかに制御できるように感じます. ORM:s には常にいくつかのバグがあり、より複雑なクエリをお尻の痛みにし、プレーン SQL で実行する場合よりも作成に時間がかかるように感じます。それとも、ORM:s に慣れていないのは私だけですか?

于 2010-08-09T18:46:07.133 に答える