当前位置: 首页 > 图文教程 > 网络编程 > ASP.NET > 从UI->DB一条龙到代码生成到EOS,谈谈快速开发

ASP.NET
关于如何操作其他窗体的控件或变量的方法
一个简单的.net remoting客户端例子
System.Runtime.Remoting.Activation.ActivationServices.CreateInstance()
单点登录—演示:passport.winspace.net
WebSerivce研究笔记
[新]可精确到1毫秒的用以在记录文件中写入自定义的调试信息(主要是时间)的组件
vs.net 2005中文版下载地址收藏
VS2005Beta2安装几点经验和体会
一个Web文件上传的C#源代码
C#重点知识详解(一)
利用C#线程机制实现应用程序的单实例运行
C#重点知识详解(二)
c#重点知识详解(三)
c#重点知识详解(四)
c#重点知识解答(五)
c#重点知识详解(六)
通过命令行方式使用NUnit进行UT
程序控制开始菜单的弹出 C#
XSL、XML教程-DVBBS皮肤制作 最基本的语法
MapX从数据库读取数据形成新图层(C#)

ASP.NET 中的 从UI->DB一条龙到代码生成到EOS,谈谈快速开发


出处:互联网   整理: 软晨网(RuanChen.com)   发布: 2009-08-14   浏览: 122 ::
收藏到网摘: n/a

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

无可否认,对于懒人来说,极大降低重复工作量的方案无疑是充满了诱惑的。所以在极大的诱惑下我花了很长的时间来思考了一下关于快速开发的问题。毫无疑问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,模式,让向着同一目标前行的同学们来一次酣畅淋漓的大讨论吧。