LINQ to SQLがSQL Data Programmabilityチームに移管になったと(参考記事)7月に報告した。この出来事により開発者コミュニティ内に、ADO.NET Entity Frameworkの利益になるようにLINQ to SQLへの取り組みが中止されてしまうのでは、という懸念が広がった。LINQ to SQLとEntity Frameworkの両方のプログラムマネジャーを務めるTim Mallalieu氏が先ごろ行った発表により、コミュニティの懸念が深刻化した(リンク)。
Entity Frameworkにはかなりの投資をしているので、.NET 4.0になる頃には、LINQからリレーショナルへのシナリオではEntity Frameworkが推奨のデータアクセス・ソリューションになるでしょう。LINQ to SQLについては顧客の声を聞いており、コミュニティから届くフィードバックにも基づいてLINQ to SQLを進化させ続けるつもりです。
Mallalieu氏の発表を文字どおりに解釈するなら、LINQ to SQLよりもEntity Frameworkによりたくさんの開発資源を充てると言っているにすぎない。問題は、Microsoftが過去の長きにわたって、「もうサポートしません」と率直に言うことなく、データアクセス技術を非推奨にしてきたことである。
LINQ to SQLの将来を深く考える前に、その過去を少々たどってみよう。Matt Warren氏は「The Origin of LINQ to SQL(リンク)」（LINQ to SQLの原点）の中で、自らのプロジェクトを「存在することすら想定されていない」ものと説明している。つまるところLINQ to SQLは、実際のORMができあがるまでの間、LINQの開発を手助けするためだけの代役であると思われていた。ところが、さらに大がかりなWinFSプロジェクトとともに、LINQプロジェクトは混乱期に入り、決して後戻りできなくなったように思われる。せめてもの何かが必要だったため、LINQ to SQLを出荷可能なプロダクトにするプロセスを開始する、という決断が下されたのであった。
一方で、別プロジェクトが始まっていた。ADO.NET Entity Frameworkは、オブジェクトモデルとリレーショナルデータベース間のマッピングを作成する完全ソリューションとして登場した。SQLサーバーに特異的なLINQ to SQLとは異なり、Entity Frameworkは理論上あらゆるデータベースをサポートできるプラガブルなバックエンドを備えることになるだろう。
Entity Frameworkは規模が大きかったため、.NET 3.5/Visual Studio 2008の期限に間に合わなかった。Entity Frameworkは「.NET 3.5 Service Pack 1」に間に合うように出来上がったが、これはどちらかというとサービスパックというよりはメジャーリリースに近かったが、不幸にもそういう名前がついた。Entity Frameworkは2つの理由から非難されている。
その複雑さゆえに、開発者に好まれない。LINQ to SQLと比較して、正しく使うために学ばなければならないことがはるかに多いのである。Entity Frameworkとは異なり、LINQ to SQLは単純なクエリやアップデートメカニズムとして使用するのがベストであり、LINQ to SQLでは基本的なテーブルマッピング以外にカスタマイゼーションは一切行わない。
データベースベンダーもEntity Frameworkを好んでいないが、理由はまったく異なる。Entity Frameworkはデータベースに特異的でなく、また、データベース特有の機能を追加する方法もまったく提供しない。これにより、Oracleのようなベンダーでは、必要とする種類のパフォーマンスと機能性の達成が難しくなっている。高性能データベースアダプタでは業界トップのDataDirect(リンク)は、OracleとSybaseのドライバを来年初頭までリリースしない予定だ。 Oracle自体は可能なリリース日付を論ずることさえない。なぜなら、MicrosoftがEntity Frameworkに追加のフックを加えない限り、Oracleが望むパフォーマンスを達成できないからである。
あまりにも逆風が強い中、軽量のORMを希望しているチームがEntity Frameworkを実行可能なオプションと見なさないのも無理もない。しかし同時に、こうしたチームはLINQ to SQLがすでに終わった技術ではないかと心配している。
「Microsoft kills Linq to SQL(リンク)」（MicrosoftがLinq to SQLを強制終了）と題した投稿の中で、Ayende Rahien氏が次のように書いている。
このようなことをするのは、Linq to SQLフレームワークに時間や金銭を投資したすべての人々につばを吐きかけるのと同じです。新機能が欲しいなどと思ったら、将来のないソフトウェアや費用のかかるポーティングプロセスとともに、結局は未解決の宙づり状態のまま放っておかれるのですから。Linq to SQLは優れたベースレベルのOR/Mであり、複数の人たちが「現在の欠陥を喜んで受け入れる。次のバージョンで修正されると分かっているなら」と私に伝えてきました。ところが、次のバージョンは出ないことになりましたし、これでMicrosoftは本当に評判を落としますね。
元々のMallalieu氏の話に関して、Jensという人物がコメントを寄せている。
つまりあなたたちはLinq To SQLが実際に行き止まりと認めているのですね？ なんてまあ、ひどいこと。Linq To SQLには「とにかく機能する」という感じがあり、私たちの新プロジェクトの基礎となっています。私はどうやってもEntity Frameworkを使うように上司を説得できないでしょう。
もう1人のコメント寄稿者のJohnが希望しているのは、両者間でマイグレートする適当な道筋とEntity Frameworkの軽量版である。
単一の「Linq to DB」フレームワークを用意したいという願望は理解しますが、提案されたEntity FrameworkがLinq to SQLと完全な互換性を提供するよう希望します。 Entity Frameworkの余分な能力のすべてを必要としない人々が、痛みを伴わずに移行できるように。私としては、自分でORマッピングをして、Linq to SQLをデータのみをグラブする単純な方法として利用する方がいいのです。Entity Frameworkは現在のところ、私が必要とするものとはかけ離れているのです！
Johnと同じような意見を何人かがコメントしている。そしてそれは正にMicrosoftがしていることである。フォローアップの投稿(リンク)でTim Mallalieu氏が次のように説明している。
過去数ヵ月間、LINQ to SQLとLINQ to Entitiesをいかにして前進させるべきかを検討してきました。一見したところ、二つは区別された技術であり、別々に進化できると断言してよいかもしれません。問題は、両者の機能の重複がすでに非常に大きくなっており、それぞれの技術のユーザからの要求により、両製品は急速な機能収束の道をたどっているということです。たとえば、LINQ to Entities（.NET 4.0とともに提供）への頻繁な要求として、POCOとLazy Loadが挙げられます。同じように、LINQ to SQLの側では、新しいマッピング戦略や、EFにはすでに備わっている他の機能を提供するように求められています。さらに両スタックに対して、UDTのような新機能や、n階層に対するより優れたサポートが頻繁に求められています。こうしたことをよく考慮し、そして社内パートナーと顧客を比較考量してからの発表となったわけですが、この発表の核心は、全体的な機能収束の取り組みに関してはEFを前進させ、いずれは多種多様な要求に対応できる単一ソリューションを提供するということを決定した点です。
これでお分かりになっただろう。結局、LINQ to SQLとLINQ to Entitiesは融合することになる。それまでの間、LINQ to SQLの開発作業は、完全に終了することはない。
顧客のフィードバックに基づき、LINQ to SQLに対して若干の投資を続けるでしょう。今回の投稿は、将来の革新に対するMicrosoftの意図を明確にするためのものであり、そして.NET 4.0の時点では、LINQからリレーショナルへのシナリオで推奨データアクセス・ソリューションとなるのはLINQ to Entitiesであるという事実を呼び掛けるものです。