この2つの製品の評決はどうなっていますか？私はこの問題に関する何かをVS2010/.net 4.0のために見つけることができないようです。Linq2SQLと.NET Framework 4.0のEF
.netに戻って3.5日.net 4.0がやって来るとLinq2SQLが死んでしまうと思う人はほとんどの人が信じています。
一方、EF4.0は大幅に改善されているようです。
これまでの仕事のほとんどは、中小規模のプロジェクトで、私の会社はすぐにVS08からVS10に移行しています。私は何を見ているべきですか？あるいは、本当に、私はEF4.0を勉強する時間を費やすべきでしょうか、それともnHibernateを見ていたほうがいいでしょうか？ （しかし、話題に戻ると、Linq2Sql - EFにもっと興味があります。）
最後に、依存関係/ポリシー注入の方がよりフレンドリーなentlib/unityを使用していますか？
ありがとうございます。
は、Entity Frameworkの（V4）が優れているいくつかの理由です：
1 - L2SQLは、本質的に時代遅れ
2である - L2SQLはPOCOマッピングをサポートしていない、EFはありません。
3 - EFには柔軟性があります（コードファースト、モデルファースト、データベースファースト）。 L2SQLは持っているだけで1
4 - EFはSPROCをサポートしています - > POCOマッピング
5 - EFは
6を必要なときに、古典的なADO.NETに戻ることができ、エンティティ-SQLを持っています - EFは（TPT、TPH）継承をサポート
7 - EFハンド・イン・ハンド・リポジトリパターン、および遅延実行とのIQueryableを経由
8 - EF成分（objectSetと、のObjectContext）容易mockableであり、DIを可能にします
新しいプロジェクトでL2SQLを使用する理由を考えることはできません。
"L2SQLは小規模なプロジェクトに適しています。私はドラッグアンドドロップして完了できます"と言う人もいます。
EF4でも同様のことができます。プロジェクトを変更/拡大する場合は、長期的には柔軟性とサポート性が向上します。それは言い訳ではありません。
HTH
L2SQLは、はるかに簡単に使い始めることができ、巨大な学習曲線を必要とせず、ほとんどの中小規模のプロジェクトに必要なものを実行します。そういうわけで、人々がEF上でL2Sを選ぶ理由です。 –
私は同意しません。それは多くの機能を持っていないので、 "よりシンプル"なようです。しかし、モデルにテーブルをドロップしてそれに対するコードを書く行為は、基本的にL2SQLとEFの間では同じです。 "新しいエンティティデータモデルを追加 - >データベースから生成 - >これらのテーブルを含める"。完了しました。 EFによって生成されたDCに対するコード。それは私にとってとても簡単です。 – RPM1984
パフォーマンスの違いはどうですか？ EFが最初に出たとき、それはかなり恐ろしく遅いです。 –
私たちはVS 2008からVS 2010に、そしてL2SからEFに移りました。
私たちはL2Sと非常によく似た方法でEFを使用していますが、必要に応じてより高度なORMを実行する柔軟性があることを知っています。
これは、小さなプロジェクトでは、おそらくL2Sを使用していると言われています。中規模から大規模なプロジェクト私はEFを使用します。
また、EFドキュメントでは、Unit Of Work、Repository、Dependency Injectionなどのいくつかのデザインパターンの調査を開始することができたため、大きな学習曲線のようでした。しかし、私はこれらのパターンがL2FにもEFにも適用されていることに気付きました。
Nhibernateについて - 私の研究（つまりSOの閲覧）は、EF4.0の最新バージョンが競争力のある製品とみなされるには十分に進歩している（POCOサポートなど）ことを示しています。ここで
L2Sはどこにもありません。 VSチームはそれを明確にしました。それは大幅な改善は得られませんが、それはまだ周りにあり、うまく動作します。
L2Sは、非常にシンプルなデータモデルを使用した小規模プロジェクトには使いやすく、使いやすいです。私にとって、L2Sを越えてEFを選択するときは、多対多のテーブルがあるか、複雑なエンティティを単一のテーブル以上にマップする必要があります。ただ、前回の回答やコメントに追加する
（3つのすべての私から+1票を得た）：
A）パフォーマンス：L2Sランタイムが原因単一層のみに（EFよりも軽量であります; EFは2つのモデル層とそれらの間のマッピングを処理しなければならない）。
EFは、L2Sよりも少し冗長なTSQLを生成することがよくありますが、生成されたクエリをプロファイリングして見ていると読みやすさに影響するのはほとんどの場合です。 SQLオプティマイザは、同じ実行計画であるのうち、最も多くはになります。ただし、クエリが非常に大きく複雑になり、パフォーマンスに影響を与える場合もあります。
L2Sは、クエリのクライアント側の最適化を行う際にもやや優れています。クライアント側で評価可能なwhere節述部を排除するので、データベースはそれらを気にする必要がありません。これは、SQL Serverのオプティマイザの作業が少なくて済み、「悪い」実行計画で終わる危険性が少なくなります。
b）L2SとL2E：L2Sは、通常のCLRメソッドを使用するLINQクエリをTSQLに変換する際に、特にDateTimeとそれに関連するメソッドに関しては、L2Eよりも若干優れています。 L2Eは多かれ少なかれ同じことをサポートしますが、それ自身のEntityFunctionsクラス：http://msdn.microsoft.com/en-us/library/system.data.objects.entityfunctions.aspxを使用します。
私の意見では、L2SとEFの両方が素晴らしい選択肢です。あなたが快適に感じるものを選んで、あなたが書いているコードの合理的な寿命の間に必要なものをカバーしてください。それを知る前に、Microsoftはさらに別のデータアクセステクノロジを発表する予定です。彼らは3〜5年ごとにそうしているようだ... :) DAO、RDO、ODBC、ADO、OLEDB、ADO.NET、型付きデータセット、ObjectSpaces、WinFS、L2S、EFなど...コード15何年も前からDAOがまだ市場に出回っているアプリでは、まだDAOが死んでいるにもかかわらず、DAOはまだ機能しています。
時には名が完全に新しいデータアクセス技術のために再利用されていますが、サードパーティ製品が適切であるならばそれは...
を何でもMicrosoftの最新のデータベースアクセス技術を構成することは常に動く標的であることに変わりはありませんあなたのために、LinqConnectを試してみてください。この製品を使用すると、異なるDBMS（Oracle、MySQL、PostgreSQLなど）でLinqからSQL（いくつかの変更を加えて）を使用することができます。
LinqConnectでは、次の提供しています、以前のL2Sで利用できない機能：
パフォーマンスに関しては、OrmBattleの最新の比較テストは、弊社のリーダーです。
また、すべてのEF機能は、DBMS-specific providersでもサポートされています。
私は、これはおそらく、元のクエリのために手遅れですけど、似た質問と、将来の人々のために...
私の心には、非常に重要な側面は、あなたが完全に新しいをやっているかどうかでありますプロジェクトを作成したり、レガシーDBで作業したりすることができます。私はレガシーDBを使用していますが、いくつかの独特な設計上の決定をしています。私はEFを使いたいと思っていますが、L2Sが完全にうまく管理している間に、これらの特質をマップすることができませんでした。
たとえば、一部のFKには関連する行のキー以外の値が含まれていたため、FK /フラグ列として効果的に倍増しました。
さらに、FK継承マッピングはDBに対して完全に失敗したので、クエリ時に型チェックと名前チェックの利点を得るためにフラットなL2Sモデルを選択しましたが、独自のマッピングレイヤーの構築は終了しました。
MSにとっての慰めがあれば、これは恐ろしい痛みです。NHibernateもタスクを実行できないことがわかりました。私の経験では、実際の使用ではDBが多すぎるので、ブラウンフィールド開発には適していません。
新しいプロジェクトでは、フレームワークの前提条件に合わせてDB設計を進化させる贅沢さがあります。既存のアプリケーションがデータ設計に依存しているので、私はそれを行うことができません。デザインを段階的に改善したいと考えていますが、すべての問題を修正すると、（リソースに対して）実行不可能な大きな移行イベントが発生します。
注：イギリスでは、ブラウンフィールド開発は、以前開発された土地に家を建てています。グリーンフィールド開発は、田舎の資源が減少しつつあることを踏まえて構築されています。私はここで用語を再利用しました。
私の下の答えはあなたの質問に答えますか？もしそうなら、正解としてください。 – RPM1984
TBH、あなたの答えが正しい答えであれば、私は気にしませんが、これらの2つの製品を比較するとき、どちらの方向を見なければならないかについて確かに私にいくつか考えました。ありがとう！ –