LINQ to SQLはデッドオアアライブですか？

LINQ to SQLと友達になったとき、まるでMSが敷物を引っ張っているように見えます。

http://blogs.msdn.com/adonet/archive/2008/10/29/update-on-linq-to-sql-and-linq-to-entities-roadmap.aspx

私の少しの研究から、EFは単純な作業にとってはやり過ぎです。しかし、この発表の後、LINQ to SQLを使い続けることに意味があるのでしょうか。

LINQ to SQLの将来を超えて、これは一般的に悪いシグナルを送信するだけではありませんか？MSが壁にビットを投げる速度を考えると、新しいビットのいずれかを早期に使用することは合理的ですか？（そして、それは親切です、LINQ to SQLの初期にはほとんどありません！）。

私のLINQ to SQL作業では、SubSonicに向かっていると思います！

更新：いくつかの新しい意見：

http://ayende.com/Blog/archive/2008/10/31/microsoft-kills-linq-to-sql.aspx

http://codebetter.com/blogs/david.hayden/archive/2008/10/31/linq-to-sql-is-dead-read-between-the-lines.aspx

1）Linq-to-SQLはすでに.netフレームワークの一部なので、Linq-to-SQLを「殺す」ことはできません。彼らができることは、それに機能を追加するのをやめることです。これは、すでにL2Sを使用している何千人もの開発者がそれを拡張して改善することを妨げるものではありません。いくつかのコア領域は触れるのが難しいですが、すでにしっかりしていて、不足しているデザイナー機能は簡単に追加できます。

2）PDC EFセッションの 1つは、EFv1の大失敗からいくつかの教訓を学んだことを示しており、L2SからEFに多くの利点をコピーアンドペーストして、それが新しいEFのものであるように見せかけています。つまり、L2Sバージョン2はEFに「再ラベル付け」されています。

3）LINQ自体（Language Integrated Query）はスライスされたアイスクリーム以来最高のものであり、L2S（Linqからオブジェクト、Linqからエンティティ、LinqからXML、Linq-to-anything）以外の多くのものと一緒に使用できます。 ）。したがって、DPグループがL2Sの採用者を[非常に多くの]強制的に[あまり人気がなく、現在欠陥のある] Entity Frameworkに強制する試みは、Linqを学ばない理由にはなりません。

次のスレッドも参照してください（これはTimのブログ投稿を部分的にトリガーしたと思います）：http : //forums.microsoft.com/MSDN/ShowPost.aspx?PostID=4061922&SiteID=1

更新1：ロジャージェニングスによるVisual Studio Magazineのカバーストーリーの2008年12月号は、L2SとEFの比較を含めて、このトピックに関する優れた記事です。http：//visualstudiomagazine.com/features/article.aspx？editorialsid = 2583

Update 2： Anders Hejlsbergはレドモンド開発者ニュースで「LINQ to SQLは死んでいません。私はあなたを保証することができます。死んでいるわけではありません。決して消えることはありません。私たちは決してやったことはありません。私たちは決してそうしません。」と述べました。

http://reddevnews.com/blogs/weblog.aspx?blog=3016

解決する必要がある質問に曖昧さが存在します。

LINQ！= LINQ to SQL

LINQのテクノロジとプロバイダーはたくさんあります。

• Linq to SQL;
• エンティティへのLinq;
• Linq to Objects;
• Linq to XML;

...そしてそれらはマイクロソフトからのものです。NHibernateを含む非MSプロバイダーも存在します。

リンクしたブログの投稿では、Linq to SQLについてのみ説明しています。

LINQの主な利点は、1つのクエリ構文を学習して使用し、それを複数のテクノロジで再利用できることです。

このことから、LINQクエリの記述で得たスキルは将来的に他のツールに移行できるため、「Linq To SQL」の将来性の欠如とは無関係であることをお勧めします。

LINQ to SQLを強制終了しているわけではありません。私たちはEF向けに最適化していますが、LINQ to SQLは確実に中止されていません:)

-スコット/マイクロソフト。

Linq（System.Linq.EnumerableおよびSystem.Linq.Queryable）を学ぶだけでなく、.net言語のプログラミング言語の拡張機能も学ぶ必要があります。

C＃3.0では、次のものが含まれます。

• 拡張メソッド（最初のパラメーターにthisキーワードを含む静的メソッド）
• コンパイラー推定型（var）
• ラムダ構文（コンテキストに応じて匿名メソッドまたは式を生成します）
• 初期化子
• プロパティのデフォルト実装（省略形）

詳細はこちら。

VB 9.0には、インラインXMLの魔法やその他の多くの機能があります（多くは、C＃の上記のリストに似ています）。

詳細はこちら。

その記事のどこでlink2sqlが死んでいるのかを正直に理解していません。

あなたがそれにリンクしたブログの投稿で言う：

LINQ to SQLについてはお客様の声に耳を傾けており、コミュニティからのフィードバックにもとづいて製品を進化させ続けます。

私にとって、これはLINQ to SQLのようなものであり、今後開発されサポートされる予定です。どうして死んだと思うの？

確かに、ここでのLINQ to SQL、LINQ to Entities、およびLINQ to [サードパーティORMの挿入]の選択は、ソフトウェア開発者が選択できるデータアクセスレイヤー手法の完全に健全なエコシステムを提供すると思います。NHibernate、LLBLGen、さらにはSubsonicなどのサードパーティプロバイダー（LINQプロバイダーを提供するかどうかは不明）は、競争を確実にさらに面白くします。

そうは言っても、MicrosoftがLINQ to SQLを放棄することは完全に悲しいことです。特に、StackOverflowがその上に構築されていても、良いフォローがあるためです。

それについての興味深いブログ投稿。Stackoverflowの投稿 に関するいくつかの関連情報。

基本的な要点は、Edity FrameworkがVisual Studio 2010およびDot Net 4の主要な開発者の時間を稼ぐ唯一のものであることを述べているado.netブログへのコメントのようです。

私の応答は-DUHです。私たちは皆これを知っています。MicrosoftはPDC 2007で、LINQ to SQLはSQL Serverの短期リリースであり、SQL Serverに対する他のLINQストーリーがなかったため、公式に発表しました。SQL Serverでのみ機能します。LINQ to SQLプロバイダーを作成することはできません。そのためのモデルはありません。これは、拡張可能なものではなく、1回限りの技術でした。

Entity Frameworkは、MicrosoftがLINQプロバイダーを構築する唯一の方法です。Entity Frameworkはかなり議論の余地のあるものであることが判明しましたが、これは部分的には、今日のLINQ to SQLのプログラマエクスペリエンスが優れているという事実によるものだと思います。Entity Frameworkは、LINQ to SQLをキャッチし、凌駕するでしょう。これは、Microsoftの未来のORM /マッピングツールであるためです。

編集-私は私のブログでこれについて少し詳細な書き込みをしました

EDIT2-IQueryableプロバイダー-LINQ to SQLプロバイダーとは異なります。独自のIQueryableプロバイダーを好きなように書くことができます。デザイナーのサポートやモデルの生成はありません。LINQ to SQLモデル生成に結び付けるために知っているGUIデザイナーモデルはありません。

私はここで問題を実際に見ていないと思います。リンクした記事から：

LINQ to SQLについてはお客様の声に耳を傾けており、コミュニティからのフィードバックにもとづいて製品を進化させ続けます。

何か不足していますか？LINQ to SQLが到着時に死んでいる印象は何ですか？

スコットガスリーは、LINQ to SQLを殺すつもりはないと私に言った：

LINQDev.comに投稿する

誰もがVB6を覚えていますか？個人的に嫌いなものでも、好きなものでも、Microsoftは数百万のコピーを販売し、企業は数百万ドルを費やして数百万のVB6のラインを作成しました。次に何が起こりましたか？

• まあ、マイクロソフトはまだVB6（一種-IDEではない）をサポートしています。
• そしてMicrosoftはまだ彼らが今でも（9月9日で）VB6の顧客に耳を傾けていると言います。
• しかし、VB6の顧客は満足していますか？VB6の発売から4年後の2002年以降ではありません。
• 何故なの？コードへの投資から代替テクノロジーVB.Netへのアップグレードパスは高価です。

したがって、そのレッスンを検討してください。私にとっては、LinqToSQLのサポートはやっかいなものになるでしょう。現在の.NETフレームワークにあるため、サポートする義務があります。しかし、それは.NET 5、6、7にありますか？それがあなたにとってどれほど重要であるかを考えてみてください（私が知っているすべての人にとって、それはあなたにはまったく関係ありません）。

たぶん、Linq to SQLの学習に煩わされるべきではないかもしれませんが、LinqからSQLに移行するエンティティはまだ残っています。

http://ayende.com/Blog/archive/2008/10/31/microsoft-kills-linq-to-sql.aspxとコメントも参照してください

2つのORMがMicrosoftのツールボックスでは1対多であることは明らかですが、私には、すべての間違った理由で間違ったフレームワークが選択されているようです。C＃チームがADO.NETチームがはるかに短い時間で行うはずの仕事をし、その仕事をはるかにうまく行ったという事実は、ado.netチームを飲み込むのは難しいです。2つのフレームワークの内部動作を知っているわけではありませんが、linq2sqlがエンティティフレームワークに持っている欠点をアップグレードする方がはるかに速くなると思います。

関与している政治が多すぎるようで、EntityフレームワークがLinq2sqlと同様にユーザーフレンドリーなエクスペリエンスを提供するとは信じられないので、これは実際にasp.netの評判を傷つけると思います。ado.netチームは、問題の明確化がせいぜい曖昧なので、asp.net mvcチームからコミュニケーションスキルを学ぶこともできます。

彼らの例のほとんどがLinq2Sqlを使用しているため、Scott Guと彼のMVCチームがここに立っていることを学ぶのは楽しいでしょう。

Linq 2 SqlとEntity Frameworkでオーバーラップの大きな領域があったことは常に少し奇妙でした。L2Sが.NET 3.5リリースでしか採用されなかった唯一の理由は、EFが日の目を見ることには大きな疑問があったためだと思います。EF1がリリースされたので、非常に大まかなv1であっても、L2Sは不要になりました。

（いいえ、StingyJack、LINQ to SQLはエンティティフレームワークを使用しません）

とにかく、私は心配しません。Timは、LINQ to SQLに関して顧客の意見を聞いていると述べています。私がL2Sに対して見た熱意から判断すると、顧客（つまり私たち）は心を語ります。

そして、KristoferAが指摘するように、彼らは実際にはL2Sを「殺す」ことはできず、凍結するだけです。そして、L2Sは、いったん洗練されれば、それ以上の開発は実際には必要ありません。L2Sプロバイダーを配置すると、LINQのすべての進歩がL2Sでも利用できるようになります。したがって、選択は引き続き私たちのものになります。

Windows Phone 7の次のバージョンであるコードネームMangoには、Linq to SQL http://jesseliberty.com/2011/05/10/coming-in-mangosql-server-ce/からアクセスできるSQL Server Compact Editionが含まれています。