从UI->DB一条龙到代码生成到EOS，谈谈快速开…

人性是懒惰的，程序员尤其如此。再懒惰的人为了让自己过得更舒服，偶尔也会很勤快，程序员还是如此。我是一个懒人，所以赞同金色海洋同学的同学都是懒人。

无可否认，对于懒人来说，极大降低重复工作量的方案无疑是充满了诱惑的。所以在极大的诱惑下我花了很长的时间来思考了一下关于快速开发的问题。毫无疑问VS.NET工具本身就是一个非常优秀的快速开发的系统（比起java来说确实要快速很多），但是对于懒惰的我们来说却是不够的。而且在多层架构下要快速开发使用VS.NET还是会产生很多重复的代码。这对于懒惰的我们来说是极其要命的。所以我们不顾一切的想要 去解决这个问题。

其实最开始进入我们视线的是代码生成器，当时我在负责一个电信项目的开发，中途接手项目，发现这个项目采用了类似duwamish的架构方式。 恩，熟悉我的朋友都知道是VNET，这是最早的微软的一个架构师设计的，想法不错，但是奈何数据访问的代码实在是太多，而参与项目的实习生的水平参次不齐，结果写呀写的就出来了很多很ugly的代码，事实上大家都知道数据访问的代码大同小异，所以我就想是不是可以直接生成代码，于是就自己写了个生成数据库访问类的程序（当时很傻，很天真，其实网上已经有了类似的程序）。

后来项目赶起来，人手又不够，人人都要从页面到数据库一网打尽，结果又觉得 其实在页面上也有很多的重复代码，每个控件取值，验证，做业务处理，写数据库。当时还在2003的时代，还没有FormView之类的东东，于是项目组的另外一个同学就提出了扩展Subsonic的方案，弄出了一个ui->db一条龙的东西。但是发现对大型的项目不是很实用，遂放弃之。

其实其间又考察过另外一款代码生成器，不过这个比我写那个强大多了，直接从数据访问到页面全部生成好了，那个工具连sln都生成出来了，项目都分好了。然后我们需要做的就只剩下了修改代码。不如被否决的原因也很自然，如果修改了代码因为模型改变而需要重新生成的话，那么修改就前功尽弃啦。不重新生成而手动修改的话因为生成的代码是按照分层的架构设计的，所以，和之前我们讨论的一样，分层是不能解决减少修改代码的问题的。让我感觉代码生成有点邪恶的感觉。

不过其间经过这段时间的工作，我发现其实代码生成并不是邪恶的，vs.net在很多情况下已经悄悄的使用了代码生成，比如生成强类型的DataSet，linq2sql的实体类，WebService的代理类。那么合理的利用代码生成其实可以达到事半功倍的效果。于是我开始重新审视EOS。普元的EOS以前我也认为是一个怪兽级的邪恶的东西（死贵，且对其生成的代码不放心，且不是.NET的）。通过拖拖拉拉，点点画画，直接生成界面，和逻辑，包括数据访问，直接包含工作流引擎以及工作流开发工具。当然不是在给EOS打广告，到现在为止那玩意儿还是死贵死贵，而且也不适用于进行网站类项目的快速原型开发，且还是个用java的。换个角度来说，Rails其实也不是由一个ActiveRecord+N多helper和代码生成器组成的“要你命3000”呢？

那么到这里回过头来再来看看 ，前几天金色海洋同学所要实现的东西是不是也是类似的努力呢？那么抛开设计原则，模式，OO什么的，其实是不是我们很多人都是在向同一个目标而去？所以这就是我为什么赞同金同学的原因。

那么抛开那些已经成为意识形态的OO，模式，让向着同一目标前行的同学们来一次酣畅淋漓的大讨论吧。