从 Dynamic Data Control 回归普通的 Data Control

我尝试在自己的软件工程项目中使用DDC，希望它能带来一些比较敏捷的特性，虽然在那么正统的软件工程课程上搞敏捷貌似有些不妥，不过其实也没有几个小组是完全按照流程来做的，反正最终所有文档齐全了演示也能让老师觉得效果不错那就行了。事实上很多小组都是随便分析一下就开始写代码，东西做出来了再补文档，哈哈……

新建了一个ASP.NET Futures的网站后，我先尝试使用DynamicDataAuto控件，发现确实如demo显示的那样“功能齐全”——所有字段都能在GridView中列出来，支持图片的直接显示，也支持外键的直接链接，一个页面上集成了所有的CRUD操作。然后我开始想细致定义这个页面，发现这个scaffold不能好像RoR的scaffold那样自动分解为低级代码，于是就尝试手工转换。首先把DyanamicDataAuto删掉，按照我的需要换上特定的Dynamic Data Control，然后发现可定制性不强，继续换……最终，页面上的控件降级到GridView了，Dynamic Data Page的特性完全没有用上，于是干脆换回普通的Page。

实际上现在的Dynamic Data Control一点都不好用，就如同ASP.NET AJAX的拖放支持一样——现成做好的控件限制太多，自定义需要实现的也太多，难以快速开发一个支持拖放特性的自定义控件。如果要使用Dynamic Data Page，那意味着Page本身为你提供了统一的Data Source，所以Page上面的Dynamic Data Control就不用设置Data Source了，然而这个特性并不能为传统Data Control所用，这就意味着一个Page上要么只用Dynamic Data Control要么只用传统Data Control。然而Dynamic Data Control的定制性实在有限，所以面对上述binary choice只能选择传统Data Control了。

暂时来说，我们也不能用Dynamic Data Control做些什么，只能等下一个版本的ASP.NET Futures看看是否有什么改善。现在的Dynamic Data Control就如同Atlas的第一个CTP那样（那时候还有<atlas:TextBox />这玩意儿），或许到最后整个模式都改掉了。