从UI->DB1条龙到代码天生到EOS,谈谈快速开发
核心提示:UI-DB1条龙到代码天生到EOS 谈谈快速开发
人性是怠惰的,程序员特别如此。再怠惰的人为了让自己过得更舒服,偶然也会很勤劳,程序员还是如此。我是1个懒人,所以赞同金色海洋同学的同学都是懒人。
无可否认,对懒人来讲,极大下降重复工作量的方案无疑是布满了***的。所以在极大的***下我花了很长的时间来思考了1下关于快速开发的题目。毫无疑问VS.NET工具本身就是1个非常优秀的快速开发的系统(比起java来讲确切要快速很多),但是对怠惰的我们来讲却是不够的。而且在多层架构下要快速开发使用VS.NET还是会产生很多重复的代码。这对怠惰的我们来讲是极其要命的。所以我们不顾1切的想要 往解决这个题目。
实在最开始进进我们视野的是代码天生器,当时我在负责1个电信项目的开发,中途接手项目,发现这个项目采取了类似duwamish的架构方式。 恩,熟习我的朋友都知道是VNET,这是最早的微软的1个架构师设计的,想法不错,但是奈何数据访问的代码实在是太多,而参与项目的实习生的水平参次不齐,结果写呀写的就出来了很多很ugly的代码,事实上大家都知道数据访问的代码大同小异,所以我就想是否是可以直接天生代码,因而就自己写了个天生数据库访问类的程序(当时很傻,很天真,实在网上已有了类似的程序)。
后来项目赶起来,人手又不够,人人都要从页面到数据库1网打尽,结果又觉得 实在在页面上也有很多的重复代码,每个控件取值,验证,做业务处理,写数据库。当时还在2003的时期,还没有FormView之类的东东,因而项目组的另外1个同学就提出了扩大Subsonic的方案,弄出了1个ui->db1条龙的东西。但是发现对大型的项目不是很实用,遂放弃之。
实在其间又考察过另外1款代码天生器,不过这个比我写那个强大多了,直接从数据访问到页面全部天生好了,那个工具连sln都天生出来了,项目都分好了。然后我们需要做的就只剩下了修改代码。不如被否决的缘由也很自然,假设修改了代码由于模型改变而需要重新天生的话,那末修改就前功尽弃啦。不重新天生而手动修改的话由于天生的代码是依照分层的架构设计的,所以,和之前我们讨论的1样,分层是不能解决减少修改代码的题目的。让我感觉代码天生有点***的感觉。
不过其间经过这段时间的工作,我发现实在代码天生其实不是***的,vs.net在很多情况下已偷偷的使用了代码天生,比如天生强类型的DataSet,linq2sql的实体类,WebService的代理类。那末公道的利用代码天生实在可以到达事半功倍的效果。因而我开始重新审阅EOS。普元的EOS之前我也以为是1个怪兽级的***的东西(死贵,且对其天生的代码不放心,且不是.NET的)。通过拖拖拉拉,点点画画,直接天生界面,和逻辑,包括数据访问,直接包括工作流引擎和工作流开发工具。固然不是在给EOS打广告,到现在为止那玩艺儿还是死贵死贵,而且也不适用于进行网站类项目的快速原型开发,且还是个用java的。换个角度来讲,Rails实在也不是由1个ActiveRecord+N多helper和代码天生器组成的“要你命3000”呢?
那末到这里回过头来再来看看 ,前几天金色海洋同学所要实现的东西是否是也是类似的努力呢?那末抛开设计原则,模式,OO甚么的,实在是否是我们很多人都是在向同1个目标而往?所以这就是我为甚么赞同金同学的缘由。
那末抛开那些已成为意识形态的OO,模式,让向着同1目标前行的同学们来1次畅快淋漓的大讨论吧。
TAG:代码,同学,项目,怠惰,懒人
评论加载中...
|