为什么我做数据库类的程序要用代码生成器,而且是前前后后,反反复复

前几篇文章提到改善工作效率的工具,这此工具对我们日常开发或多或少的有些改善。有网友对代码生成器感兴趣,有些工具还会可能会改变你开发数据库软件的思路和模式,这里我也来侃侃代码生成器

代码生成器的成长过程
1 每个类都要一个个的写,很费力。在数据库为主的日常开发中,大多的日常工作就是数据表的增删查改,大多的代码都差不多。
2 写的数据访问类多一点,我会注意每个类的命名。比如,如果表名是Pubs,我的实体类名叫PubsEntity,数据访问类名叫PubsDAL,接口层的类名叫PubsService,这样遵守一个统一的模式,开发和维护也容易理解。方法的命名也要统一,比如增加一条数据,不能有的叫Add,有的叫Insert,这样不和谐。
尽量规范,统一。
3  类的设计和方法的设计经过一段时间的锻炼,逐渐规范。还需要把他们分层,放到不同的命名空间和程序集(Assembly)中。比如,实体层的数据实体叫YiHu.IPR.BusinessEntity,数据访问层叫YiHu.IPR.DAL,接口层叫YiHu.IPR.Service,界面层都放在YiHu.IPR.Web命名空间中,
YiHu是公司名,IPR是系统模块名称。
然后把这些类分别放到不同的assembly中,修改AssemblyInfo.cs,全部项目用同一个的AssemblyInfo.cs,各个assembly版本号一致,文化,签名文件(sn.key)一致。
4 于是,各个细节地方都开始规范。但是,问题又来了,需要手动去敲键盘,当系统的实体层和数据访问代码很多的时候,经常会敲错,敲漏字符。于是,弄个代码生成器吧,直接按照规范的设计好的结构生成代码,不容易出错,即使错了,也是代码生成器的bug,一定要把他调试正确。
5  代码生成器有了,开始偷懒的日子就多了。每天可以少干两个小时的活,别人还在敲键盘的时候,你轻盈的打开你的代码生成器,新建一个数据库连接,然后点击Execute按钮,所有的代码就呈现在你面前。这样重复了几个月后,感觉做程序没有多大的技术含量。于是,开始研究架构,如何把经得起考验的各种架构溶入到你的开发中,让程序开发变成一种充满智慧的体力劳动。终于把Dumwash,PetShop,DinnerNow的代码架构研究熟练了,可是问题来了,还是要从头开始写代码呀,这样又得一个个字符的敲,又回到原始社会。于是,又开始研究如何把最新研究的架构和代码生成器结合起来,一举两得。经过一段时间的研究,发现要改变一下代码生成器,要适当提取一些代码出来,放到一个公共的框架中,为了让新研究的架构能运行,不得不这么做。
6  经过一段时间的磨合,代码生成器终于可以和各种架构结合起来,于是一个个项目模板产生了。不同的项目模板代表不同的架构方案,我还特地做成模板,方便新项目的开发。这种日子可以持续很长时间。
7  又有新的发现,于是不停的改进你的代码生成器。当需要WCF支持的时候,给每个实体类自动加上[DataContract],给接口层类加上[ServiceContract];有的人喜欢拼凑SQL语句,有人喜欢用参数,于是给代码生成器同时提供两种模式的代码生成;有的项目用C#写的,但是负责维护的人只会用VB,于是用CodeDOM技术给代码生成器升级,让它同时支持生成VB和C#两种代码;有时候发现单独打开代码生成器很麻烦,而且很慢,界面也比较难看,于是研究Visual Studio SDK,把代码生成器直接集成到Visual Studio中,这样打开一个工具(Visual Studio)就可以完成所有的工作,真舒服;有时候发现生成的代码不改不行,改了又不好识别,于是把生成的代码加上partical标签,放到一个文件夹中,自己手写的代码放到另一个文件中,因为CLR是以方法为单位做JIT的,那些不再被使用的由代码生成器产生的代码,可以不用管它,也可以在适当的时候把它移除,只要用一个key就可以了(在方法名上点击右键,查看引用,如果这个方法被用过,底部的窗口会调出被调用的地方,如果没有被调用过,可以放心的去掉。这个重构功能,比查找功能强大很多)
于是,工作变得很有趣,也离不开代码生成器。

代码生成器的组成
1  SQL语句生成。自动生成SQL语句的CRUD脚本代码,还有喜欢用存储过程的,也要生成存储过程
2  类生成器。 对照数据库的表,生成实体类,数据访问类,接口类,界面绑定代码。
为了支持不同类型的数据库,需要生成不同类型的数据库访问类,比如对SQL Server,参数是SqlParamater,对于Access系列的数据库,参数是OleDbParameter。我的代码生成器的方案是,生成统一的代码,由于我生成的代码是基于Enterprise Libiary的,企业库本身支持访问多种类型数据库,我生成的代码自然就持多种数据库。不过,一个SQL Server就够折腾的,我怀疑支持多种数据库的现实性。
购买过SQL Server 的正版License后,我想你的boss同意你去折腾Oracle的可能性很小。小到很多公司的员工在抱怨公司还没有发年终奖的时候,其实有更多的公司根本就没有年终奖。
3  界面生成. 生成基本的界面控件,如表名是Employee,有一个字段Name;于是生成一个Table,ID是Employee,生成一个文本框txtName,还同时生成数据实体和界面绑定的代码,这样才有生产力。你需要把界面中需要的地方换成DropDownList,或DateTimePicker,大部分界面代码还是可以直接用的。
于是,代码生成器变得复杂,也变得专业。

反对的声音
我看过一些关于代码生成器的评论,大家说的有道理。
1)要按照模板来生成代码才有意义,否则它根本就是个字符串生成机,于是把CodeSmith搬出来论事。
2)有的说代码生成器生成一大堆的没有质量的垃圾代码,有什么用呢。代码生成只是个字符串生成器,输出代码质量差,不灵活。
3) 老板如果知道有这个东东,会缩短项目的deadline, 还是不用的好,就当它不存在一样。
于是,代码生成技术并不流行,虽然Visual Studio也是个很好的代码生成器,但是都不承认。

关于数据访问模式
在《领域设计模式》这本书,作者提到过三种数据访问模式
事务脚本:我们经常用的,我的代码生成器中用到的,就是这种模式,简单,但是缺乏灵活性,说白了就是缺乏面向对象的设计,经不起变化的考验,只是一堆的类堆砌而成的系统。

ORM:对象实体框架。有了这一层,我们可以完全忘记数据库的存在,ORM会自动生成native的数据库SQL脚本,自动处理好对象之前的关系。
比如NHibrnate,NBear,这两个框架以前都折腾过,实际运用他们做过一些小项目,还做过相关的小工具来辅助开发。现在,支持NHibernate的工具都可以直接集成到Visual Studio中,也有相对应的代码生成工具流行于各大论坛。唯一的问题是如果这个项目不是自己带头的,你没有选择NHibrnate的权力,此外,这个框架会让你远离ADO.NET,你根本看不到亲切的SqlConnection在那里,取而代之的是一大堆的Session,SessionFactory,学习成本陡然增加;在一个团队中,有的会NHibrnate,有的不会,难道要给单独的时间去学习,这样对有的员工不公平;我经历过的一个ERP项目,当项目进行到中期的时候,人换得比较厉害,换调(也可以说是走)了近一半的开发人员,新手都不会NHibrnate,你一点办法也没有,项目的deadline紧急,只好不会NHibrnate的,直接用ADO.NET,用Application Block。
但是,如果你做.NET开发,连ADO.NET也不会,你可能会找不到工作。学习太偏的领域的知识,比如NHibrnate,学起来有风险,高处不胜寒,用起来也有风险,而且也不确定哪一天你才有决定权力去用这个东东,即使开始用,你也要对NHibrnate的细节方面很熟悉,很熟悉。

领域模式:我对这个模式的理解不深,大概你需要用纯OOP的方式去设计一个软件,而不像我们一开始就瞄准数据库,从数据为脚本开始。

于是,代码生成器得到进化和改良。虽然有些改良像清代的《戊戌变法》,理论知识一套一套的,有板有眼,但做起来并不容易,把各种思想溶入到日常的开发工作和工具中,是个慢长的进化过程。
我在接触代码生成器之前,也研究过这三种模式,至少我研究过,做出的东东也不至于太烂。
流行于各大论坛的代码生成器也很多,我也有用过一些,从改善工作效率的角度来看,它们都很不错。
 
在这篇文章里,我没敢截个图放出来,我理解反对代码生成器的开发人员的感受。
每个工具只是为改善我们的工作效率而产生的,如果一件工具或方法不能改善你的工作效率,你要毫不犹豫的把它去除。做了几年的数据库软件和一年的报表,我本身开发能力并不强,自己折腾的代码生成器也很烂,经常死掉,有一些特性一直想加入到代码生成器中,都没有时间去做,也有点不敢做。
借助于代码生成,我能有更多的时间花在系统的细节方面,尽量做出专业的系统,界面要专业,出错提示要专业,各个细节要多听用户的想法,直到取代它心目中神圣的EXCEL。
也因为代码生成,我的系统设计能力一直没有长进,有固定的模板,固定的代码生产方式,可能考虑的各个方面(分页,主界面,后台,基础框架,通用用户权限角色)都考虑好了,于是花费更多的时间在分析和理解客户需求方面,与客户沟通。主动承担项目的前前后后的大事小事,也许这是一个信号:转行

做程序快做到了三十岁,心里不虚,技术不强也不太烂,各种技术方案多多少少都有点积累;
经历过一些大大小小的项目,有时候真的怀疑自己,我这个性格适合去做项目吗?程序员出身的性格,有多少人能幸运的转行成管理,多乎哉?不多也。

如果有积累的习惯,你可能早就有自己的代码生成器,可以定制修改的,如果没有,从现在开始也不晚。
每三个月或半年要主动思考一下,如何改善工作效率,几年后,你工作的效率会比现在成倍的提高。
我给你一个方向,你可以朝那里努力,也许我本身并不怎么强,会误导你;
To believe it or not, It’s up to you.

posted @ 2010-02-05 08:59  信息化建设  阅读(4471)  评论(23编辑  收藏  举报