有一段时间，也怀疑自己，是否有必要继续维护代码生成器？因为微软的LINQ技术、EF技术都出来了，而且资料也开始越来越多了，代码生成器的功能越来越被这些新技术取代了，是否有必要还继续维护代码生成器？今年的3件事情给了一些启发、加强了对代码生成器的认识高度。

   1：在国家某部委开发项目，数据库需要用的是Oracle，而且需要控制的数据有上千万条记录，也不用SQLServer数据库，LINQ技术、EF技术派不上用处，应该也是暂时无法用得那么熟练，记得只对SQLServer数据库的支持是很好。

   2：在开发某银行的现金管理系统，数据库需要用的是DB2，也明确指定不能用SQLServer数据库，LINQ技术、EF技术派不上用处，若我的配套的基础程序是依赖这些技术的，估计那些业务实现功能都需要重新写过一遍，那是很要命的事情，而且那些基础组件的测试、完善、稳定都是耗费了几年时间，不是几天就可以折腾到DB2上的事情。

   3：前几个月，给有3-4年做日本外包开发的同行推荐了代码生成器的用法，这个朋友也是用C#.NET做开发，在北京工作，最近他也用了通用权限管理系统中的代码批量生成器，感觉用起来很爽，很多代码都不用自己写了，省老事情了而且还给身边的朋友在推广，他觉得这么改进了一下后，很多重复代码不用自己人工写了，可以集中精力去做业务实现了。

   自己也有一些感触，我们专业做项目类开发的，没办法定位只做SQLServer上的各种应用开发，LINQ技术、EF技术有很多优点，用起来也会很爽，但是有一些基础性的，可以重复利用的组件，不能完全依赖这些技术，需要考虑充分的通用性、兼容性。某个业务性质的开发完全可以用这些新技术，也支持用这些新技术来开发，将来也好维护，也更规范一些，也符合技术潮流。

   经历了以上几件事情后，我对代码生成器的价值观也越来越明朗，有一套自己能驾驭的代码生成器还是有必要，毕竟我们会遇到开发各种场景下的业务应用系统，可能是SQLServer的、也可能是Oracle的、还可以是DB2的，有时候还是MYSQL的数据库，不可能为每套系统都开发以系列配套的组件，那根本没精力维护的。

   赤手空拳上战场好？还是带上轻机枪上战场好？代码生成器就是。。。