Dynamic Dataの本質ってこんな感じかな
Dynamic Dataを一通り調べると、データベースをEntity FrameworkかLINQ to SQL使ってデータモデル化させてデータモデルを上手く弄るモノなんだなぁと感じます。
つまり、GridViewやListView自身は（基本的に）ほぼ手を入れられることを想定してなくて（DataSourceにも）、メタモデル、メタデータを属性などで制御してあげるってのが想定されている利用方法なんだろうなぁ。
結構好き嫌いがはっきり分かれるアプリケーション基盤かもしれない（そこは弄りたいでしょ！って思う方も多いと思うので）。
理由1
LinqDataSourceコントロールの利用
そもそもLinqDataSourceコントロールって*ですべての列引っ張ってこないと"更新、編集、削除"等はできなくなるのでデータは全列引っ張ってきている*1。
理由2
複数テーブルもすべて1つのテンプレートを利用している
Webサイトかプロジェクト作って、LinqDataSourceコントロールとGridViewあたりを貼り付けて（もちろんLINQ to SQLも用意）、データソースの指定をするとGridViewには指定したテーブルの列等を自動生成してしまう。
これって、複数テーブルを1つのWebページで対応しようとすると結構工夫が必要になるんですが、Dynamic Dataの場合DynamicDataManagerが上手くこの辺りを賄ってくれてます。aspxファイルだけ見ても、どうやってGrid表示してるんだ？って思うかもですが、ここはDynamicDataManagerが頑張ってくれてるとわかればOKかな。
開発者の意図?
ある程度汎用的なテンプレートにしてしまいたかったと思うので、Dynamic Dataアプリケーションのプロジェクト作成すると、結構な量のファイルが作成されます。これって、動く物の基盤はこっちが提供するから、開発者の方々はView部分は基本的に気にしないで（ページ自身のカスタマイズや、ユーザーコントロールの追加はできます）、メタデータ、メタモデルの開発に注力してね。ってことなのかなーと。
多分、現時点でのLINQ+Entity Frameworkの関係上Dynamic Dataを大きく改良するのって結構難しくて（Webテクノロジでもありますし）、”更新・編集・削除・挿入”ができれば及第点ではあるかと思います。
これってASP.NET MVCやASP.NET AJAXと大きく違う点はメインで利用することは少なそうな感じかな。ASP.NET関連のテクノロジで構築したソリューションをサポートするために利用するシナリオが多い気がします。
*1:EntityDataSourceコントロールも同様の仕様なのかは未確認でした…後で確認予定
