Entity Data ModelとLINQ to SQL は同時に使えない

ASP.NET MVC では Entity Data Model と LINQ to SQL が同時に使えません。つーか、同時に使うな、ってのがホントなんでしょうが、まぁ、Html.DropDownListFor メソッドが、あっちが動いたのに、こっちが動かない、という現象があったもので（この話が後日）。

まだ、公開されていませんが

連載! コードで学ぶ ASP.NET MVC アプリケーション開発入門 | Code Recipe | MSDN
http://msdn.microsoft.com/ja-jp/asp.net/gg490787

の次回は、Entity Data Model なんですね。

ですが、日経さんで出している「ひと目でわかる ASP.NET MVC」のほうは、実は、LINQ to SQL を使っているのです。
このあたり、執筆時に悩んだのですが、書籍のほうにはデータベースのややこしいところを取り込みたくなかったわけです。

ADO,NET Entity Data Model が ADO.NET の後継であることはわかっていたのですが(多少、不勉強ということもありますが)、このあたり、モデルを直結させてしまうとモデル自身の効用がわかりづらくなる、っていうのと、モデルの中にテーブルを含めるとちょっと、ってな感じで、薄さ(苦笑)を優先させたのです。

さて、

Entity Data Model の良いところは、SQL Server 2008 と直結しているところです。Visual Studio 2010 上でデザイナが動くのは、Entity Framework としては一部のところで、本音のところはコマンドラインで DDL と直結させたりする「親和性」のところにある気がします。DI コンテナなんてのを想起させます。なので、リレーション(外部キー)や主キーなんかが結構な役割を果たしています。

一方で、LINQ to SQL ってのは、(乱暴に言えば)オブジェクト指向に持ち込んだ SQL みたいなもので、ラムダ式やら無名関数やら拡張メソッドやらで、F# の影響を強く受けているわけですね。つまりは、プログラム言語からのアプローチ。

この話、どちらが「勝ち」という訳でもないわけで、ADO から続く DataSet やら、オブジェクト指向アプローチの O/R マッピングやらの歴史があるので、こんな感じなんですね。他にも、データベースには、ストアドプロシージャとビューがあるわけで、このあたり、「ビジネスロジック」を何処に置くのかとか、ある意味で「開発者に任せるのか」、「データベース管理者に任せるのか」というアプローチの違いも反映されていたりします。

だからという訳ではないんでしょうが（笑）、

こんな風に、Entity Data Model を追加した後に、LINQ to SQL も使いたいかなぁ、と思って追加すると、

ありゃ、LINQ to SQL のほうで、コンパイルエラー

どうやら、テーブルをインポートしたときの、TProduct クラスで既に _id が使われている模様。

実は namespace が両方とも、MvcApplication7.Models という形で Models に入っていて、TProduct クラスは partial で作ってある（分割されている）ので、クラス名の重複よりも、各メンバの重複が優先されてエラーになっているんですね…って、ややこしい。

ちなみに、別のテーブルをインポートすると大丈夫なので、正確には、

「同じテーブルを Entity Data Model と LINQ to SQL では使えない」

ですかね？　namespace を変えればよいのかな？