ASP.NET DynamicDataのAPIはASP.NET Abstractions/Routingの応用としては出来が悪い

https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=376426

ASP.NET AbstractionsやASP.NET Routingは、ASP.NETエンジンから切り離して実行できるように作られたフレームワークだったはずなのだけど、これらの上に乗っかって実行されているはずのASP.NET Dynamic Dataは、全然そういう風に出来ていなくて、がっかりしてしまう。

たとえば、単なるコンソールアプリケーションでMetaModel.VisibleTablesやMetaTable.ListActionPathといったプロパティにアクセスしようとすると、HttpContextWrapperをHttpContext.Currentから生成しようとしてエラーになる。HttpContext.Currentは、ASP.NETが動作していない時はnullを返すからだ。もちろん、Routingの実装クラスであるDynamicDataRouteは、これらのプロパティに依存するので、同様にエラーになってしまう。

MetaModel.Defaultは変なstaticプロパティで、そのstaticコンテキストで一度もMetaModelインスタンスが生成されていないとnullを返すが、一度でもMetaModelインスタンスを生成すると、そのインスタンスが返される。ASP.NETのアプリケーションは、通常はそのアプリケーション用のAppDomainを1つ生成されてその中で動作する形になるので、通常はこれで問題ないということになるのだろう。

System.Web.Abstractionsがきちんと使われて、テストがきちんと出来るようになるには、まだいろいろ越えないといけない壁や越えられない壁があるのかもしれない。ASP.NET Abstractionsの設計として、HttpContextBase.Currentとか用意しておけばまだ良かったのではないかという気がする。staticメンバでCurrentを取得するというのはあまり好ましくないかもしれないが、どうせ1つのASP.NETアプリケーションに1つのstaticコンテキストというのは前提になっているのだから、その辺はあきらめても問題なかったような気がする。というか、まだHttpContextBase.Currentがある方が、まともなコードが書けると思う。

まあそんなわけでfeedbackしてみた（冒頭のリンク）。