数据库开发基础 代码生成器的成长过程

　　每个类都要一个个的写，很费力。在数据库为主的日常开发中，大多的日常工作就是数据表的增删查改，大多的代码都差不多。

　　写的数据访问类多一点，我会注意每个类的命名。比如，如果表名是Pubs,我的实体类名叫PubsEntity,数据访问类名叫PubsDAL,接口层的类名叫PubsService,这样遵守一个统一的模式，开发和维护也容易理解。方法的命名也要统一，比如增加一条数据，不能有的叫Add,有的叫Insert,这样不和谐。

　　类的设计和方法的设计经过一段时间的锻炼，逐渐规范。还需要把他们分层，放到不同的命名空间和程序集（Assembly)中。比如，实体层的数据实体叫YiHu.IPR.BusinessEntity,数据访问层叫YiHu.IPR.DAL,接口层叫YiHu.IPR.Service,界面层都放在YiHu.IPR.Web命名空间中，

　　YiHu是公司名，IPR是系统模块名称。

　　然后把这些类分别放到不同的assembly中，修改AssemblyInfo.cs，全部项目用同一个的AssemblyInfo.cs，各个assembly版本号一致，文化，签名文件(sn.key)一致。

　　于是，各个细节地方都开始规范。但是，问题又来了，需要手动去敲键盘，当系统的实体层和数据访问代码很多的时候，经常会敲错，敲漏字符。于是，弄个代码生成器吧，直接按照规范的设计好的结构生成代码，不容易出错，即使错了，也是代码生成器的bug，一定要把他调试正确。

　　代码生成器有了，开始偷懒的日子就多了。每天可以少干两个小时的活，别人还在敲键盘的时候，你轻盈的打开你的代码生成器，新建一个数据库连接，然后点击Execute按钮，所有的代码就呈现在你面前。这样重复了几个月后，感觉做程序没有多大的技术含量。于是，开始研究架构，如何把经得起考验的各种架构溶入到你的开发中，让程序开发变成一种充满智慧的体力劳动。终于把Dumwash,PetShop，DinnerNow的代码架构研究熟练了，可是问题来了，还是要从头开始写代码呀，这样又得一个个字符的敲，又回到原始社会。于是，又开始研究如何把最新研究的架构和代码生成器结合起来，一举两得。经过一段时间的研究，发现要改变一下代码生成器，要适当提取一些代码出来，放到一个公共的框架中，为了让新研究的架构能运行，不得不这么做。

　　经过一段时间的磨合，代码生成器终于可以和各种架构结合起来，于是一个个项目模板产生了。不同的项目模板代表不同的架构方案，我还特地做成模板，方便新项目的开发。这种日子可以持续很长时间。

　　又有新的发现，于是不停的改进你的代码生成器。当需要WCF支持的时候，给每个实体类自动加上[DataContract]，给接口层类加上[ServiceContract]；有的人喜欢拼凑SQL语句，有人喜欢用参数，于是给代码生成器同时提供两种模式的代码生成；有的项目用C#写的，但是负责维护的人只会用VB，于是用CodeDOM技术给代码生成器升级，让它同时支持生成VB和C#两种代码；有时候发现单独打开代码生成器很麻烦，而且很慢，界面也比较难看，于是研究Visual Studio SDK，把代码生成器直接集成到Visual Studio中，这样打开一个工具(Visual Studio）就可以完成所有的工作，真舒服；有时候发现生成的代码不改不行，改了又不好识别，于是把生成的代码加上partical标签，放到一个文件夹中，自己手写的代码放到另一个文件中，因为CLR是以方法为单位做JIT的，那些不再被使用的由代码生成器产生的代码，可以不用管它，也可以在适当的时候把它移除，只要用一个key就可以了（在方法名上点击右键，查看引用，如果这个方法被用过，底部的窗口会调出被调用的地方，如果没有被调用过，可以放心的去掉。这个重构功能，比查找功能强大很多）

　　于是，工作变得很有趣，也离不开代码生成器。