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

 

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

代码生成器的成长过程
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.