2007年6月19日星期二

从 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 />这玩意儿),或许到最后整个模式都改掉了。

没有评论:

发表评论