LINQ to SQL は Entity Framework ほど活発に開発されない可能性が高いため、Entity Framework に切り替えるのが最善だと思いますか?
個人的には、非常に自然に感じる LINQ to SQL と比較して、EF は非常に扱いにくく、使いにくいことがわかりました。
編集：私は最近、この潜在的な決定に対する私の気持ちについてブログに記事を投稿しました...
Chad Moran
質問する
3425 次
8 に答える
22
IMO、現時点ではありません。
LINQ-to-SQL と EF の間で"サンダードーム" シナリオが展開されているため、(特に最近の発表から) EF が大幅な改訂を予定していることは明らかです。何が起こっても、(数年以内に) EF は現在の EF とはまったく異なるものになることはほぼ確実です。または確かに「十分に異なる」;-p
そのため、私の見解は次のとおりです。シンプルに固執します。シンプルなのは LINQ-to-SQL です。
悪名高い複雑なシステムがすぐに変更されることがわかっている場合、そのシステムを学習するメリットはあまりないと思います。
LINQ-to-SQL については 100% 賛成です ;-p
今すぐ LINQ-to-SQL 以外のものが必要な場合は、NHibernateまたはLLBLGen Proを検討します。
(編集- 更新として、私の立場はこことここで少し柔らかくなりました- しかし、私はまだ LINQ-to-SQL を私の主要なツールとして使用しています; また、- LINQ-to-SQLはまだ完全に死んでいません;- p)。
于 2008-11-09T20:28:25.937 に答える
7
私は、L2SQL を内部で使用して現在運用中のいくつかの MVC プロジェクトを完了しましたが、使用するのは非常に楽しいと感じました。私は現在、新しいプロジェクトに着手しており、L2SQL の死を宣言する以前に引用された記事を考慮して、EF と L2EF を使用してそれを作成することにしました。ほんの数日後、L2SQL に戻ることにしました。以下に示すひどい構文または不必要なルックアップを使用して、挿入用の外部キーを設定する必要があるなどの単純なことに、私はショックを受けました。
foo.Foreign_TypeReference.EntityKey =
new EntityKey("DataContextName.Foreign_Type", "Foreign_Type_Id", ForeignTypeId);
それよりも：
foo.Foreign_Type_Id = ForeignTypeId;
L2SQL には機能のサブセットがあるため (より適切に実装されていますが)、L2SQL を将来のバージョンの EF に移植することはそれほど難しくないと思います。Single() や SingleOrDefault() など、L2SQL にあり L2EF にはないいくつかの機能は、いくつかの拡張メソッドを作成することで EF に移行できます。L2SQL を使用してシステムを実行し、後で EF がそれほど臭くないときに移植するのにかかる時間ははるかに短いと思います。
于 2009-02-03T09:04:37.313 に答える
6
データベース駆動型の開発を行っている場合、現在 EF には真の利点があります。
私は LINQ to SQL と EF の両方を使用し、EF v1 の多くの小さなフラストレーションに取り組みました。
しかし、私にとって EF v1 が勝った理由の 1 つは、データベースウィザードによる驚くほど優れた更新です。信じられないことに、これは実際に機能します。些細なことのように聞こえるかもしれませんが、データベース ファーストの設計を行っている場合は、ツールを使用してクラスを作成したいと考えており、変更を加えるためだけにモデル全体を再生成する必要はありません。
これだけでも EF v1 が私の選択になります。EF v1 の高度な機能は無視することをお勧めします。EF v1 が目指している野心的なプラットフォームとしては、まだ使い道がありません。
EF v1 の扱いにくさを我慢すれば、将来に向けて最適な位置に立つことができます。
ピート。
于 2008-12-11T00:41:09.603 に答える
3
MarcGravellに同意する必要があります。おそらく、Entity Frameworkの次のバージョン（.net 4.0 / VS2010）がリリースされると、EFを使用する利点があり、それまでに、EFの現在のバージョンとは大きく異なる可能性があります。
それまでは、少なくとも、本番環境に影響を与えることのないテスト/実験コード以外のペストのようなEFは避けます。
EF msdnフォーラムには、EFがプライムタイムの準備ができていない理由に関する例がたくさんありますが、明確な勝者である特定の例が1つあります。通常は単純な5つのテーブルクエリ（10〜15行のSQL）です。EFとEntityDataSourceコントロールを使用すると、1500行を超えるSQLになります。
http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=3874607&SiteID=1
http://paste-it.net/public/q6ed5c2/
そして、EFの将来については、Microsoftが一夜にして大きな戦略的事柄の方向を変えてきた歴史を踏まえて、EFに関する現在の「戦略的目標」が数年後に実現するかどうかは誰にもわかりません。私は確かにそれに賭けないでしょう。見る：
http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=4100399&SiteID=1#4107623
于 2008-11-17T03:36:34.847 に答える
2
記録として、LINQ to SQL の将来についてのいくつかの躊躇がここで表明されています。
于 2008-11-09T20:41:05.367 に答える
2
LINQ to SQL は、SQL Server (または SQL Server コンパクト) を使用しない限り、オプションではないように思われるため、それを避けて EF を使用するのに十分な理由でした (PostgreSQL を使用したかった)。
EF の v1 には、お勧めするのを躊躇させるほどの十分な機能が欠けていることは間違いありません。EF のバージョン 2 (リリース時) は、切り替えを真剣に推奨できる最初のバージョンになるようです。
于 2008-11-19T14:38:17.427 に答える
1
ここで詳しく説明するように、かなりの数の経験豊富な開発者が「ADO .NET Entity Framework の不信任投票」を行っています。
ADO.Net チームによって.Net 4.0で大幅に改善されることを期待していると思います。
これは最近の PDCのビデオです。
于 2008-11-09T20:38:01.410 に答える
-1
最近、どの ORM プロジェクトを使用するかを調査する必要がありました。最初に-L2Sを試しました。まったく悪くはありませんでしたが、すでに時代遅れになっています (MS はもうサポートしません)。そのため、L2E を調べ始めました。生成されたコードには問題ありませんが、エンティティのすべてのフィールドを埋めないようにストアド プロシージャを使用できるようにするためだけに、偽のビュー、エンティティ、およびそれらの間のマッピングを作成することは、やり過ぎでした。そして、データアクセスレイヤーを分離したかったので、生成されたオブジェクトから作成したオブジェクトにデータをマップする必要がありました。
この組み合わせに固執するために、NHibernate + Fluent NHibernate + LINQ to NHibernate を試すのに数時間かかりました。
于 2009-05-24T13:02:20.057 に答える