什么是静态代码生成？静态代码生成区别于Visual Studio集成的动态生成的方式。静态代码生成弊大于利,所以建议初学者要思考代码生成背后的思想，不要在DIY自己的静态代码生成器上花费更多的时间和精力。
为什么需要框架和代码生成？
为什么会有代码生成和框架？只考虑没有使用代码生成和框架的编码开发，有2种大量出现相似或重复代码的地方，一种是基础架构代码，如安全验证、权限判断、日志记载等。另一种是当需要进行数据存取更新时产生的大量的针对数据存储接口的代码。在多人开发时，由于多个模块都需要调用上述2种代码，除了大量的重复外，很可能会产生同一功能性代码的多个版本，对测试和维护都带来很大的不便。
持续应用重构可以抽象出可复用性的框架，比如EntLib等。框架的优点很多，使用框架在很大程度上可以减少重复代码，提高编码效率，但框架的使用需要学习成本，而一旦使用框架，就要受框架的各种约束，但很多时候这是值得的。代码生成是另一种解决方案，以统一生成简单逻辑代码的方式，避免了在多处出现版本不一的相似或雷同代码，虽然代码总量膨胀了，但测试和维护的压力减轻了。
ORM和数据访问代码生成时必须的吗？
抛开基础架构类代码的问题，ORM和静态的数据访问代码生成经常是被拿来并列的讨论的，其中关于性能和多数据库支持尤为火热，动不动总要拿出来各种讨论，这样跑偏是不好的。业务对象的分析和建模是从面向对象的角度去考虑，而涉及到对象状态的持久化，一般都是采用关系数据库存储，而关系数据库分析和设计针对数据冗余及其引起的各种问题。两个系统的关注点如此不同，产生了对象关系映射的问题。可以说对象关系映射是个问题，也可以说根本不是问题。考虑我开始编码，无论是否采取业务对象方式，在设计存取更新时直接写ADO.NET代码通过SQL语句或存储过程来操作数据库中的Table，怎么样的操作在程序里是什么意思，在我们头脑中很清晰，这时候完全意识不到有什么对象关系匹配的问题。
业务对象的规模和数量越来越大后，我们采取重构和框架后，仍然可以在没有ORM或数据访问代码生成的情况下继续下去。这样说来无论是ORM还是代码生成对我们来说不是必要的。也就是说，不了解ORM和代码生成的优点和缺点，采用ORM或代码生成给我们带来的不一定是便利。就像我刚才所说，非要强调ORM对多数据库的支持，或者ORM性能的损失，而不去抓住ORM在某种程度上解决对象关系映射带来的便利和限制，实在是没有意思。数据访问的代码生成方式更没有必要一再强调多数据支持，和生成包含各种框架调用的代码。
要动态代码生成，不要静态代码生成
代码生成也是为了解决重复代码问题的。通过代码生成工具来维护重复代码。而常见的静态代码工具则不具有这个功能，因为无论从对象还是数据表来生成还是从代码生成数据表，一方修改后，都导致了重新生成和拷贝粘贴。往小了说一旦业务模型或存储模型发生变化，代码生成会花费教多的时间来调整代码，往大了说无论从业务模型还是存储模型来生成，都是强制匹配，甚至比ORM框架的匹配限制更大。
业务模型的调整必然引起存储模型的重新审视和调整，而不是简单的根据某种规则重新生成表定义，存储模型的调整也必然会引起代码的重新生成，而静态代码一般只能手动重新生成，不是你敲下一行代码，就会自动生成的。所以解决重复代码，静态代码生成不适合，至于生成项目文件的功能，除了演示制作demo在实际应用中很难用得上。
ORM是一个框架，引入必然带来限制，改进应该在2个方面，一个是稳定性。一个是尽可能多的提供支持达的匹配方案，在使用ORM时，通过尝试多种匹配和大批量的数据测试来最终决定应用的匹配规则。代码生成只有动态生成才是发展方向，Visual Studio的新近版本对此提供了大力的支持，动态代码检测和生成可以在Visual Studio的插件（addin）中可以通过EnvDTE.Project.CodeModel和EnvDTE.FileCodeModel得到支持，也可以安装Visual Studio SDK及Visual Studio Integration SDK通过编写扩展（vsix）使用CodeDom和T4方式。
一定要DIY静态代码生成器
虽然我强烈建议要动态代码生成，不要静态代码生成，因为动态代码生成可以完成静态代码生成几乎全部的任务，又可以实时根据用户输入自动调整。但如果有初学者一定要或者已经在自己尝试静态代码生成器，我提供几点参考，是几年前自己开发代码生成时的经历，可能已经不太适用于当前。
1.连接到多数据库，可以用VS公开的DataConnection项目，不必为怎样提供Visual Studio数据连接的方式浪费时间。
2.想解决方案中加入网站时，网站项目的GUID是常量（E24C65DC-7377-472B-9ABA-BC803B73C61A）。
3.CodeDom、反射和特性方面的基础。
4.对分层和领域模型概念模糊，请阅读《领域驱动设计》[Evans DDD]\《领域驱动设计和模式应用》[Nilsson ADDDP]\《企业应用架构模式》[Fowler PoEAA]。
5.如果对界面有更多要求，参考伍华聪的博客。
后记
自从老赵、双鱼座等务实有想法人，走的、消失的、潜水的以来，越来越感觉能够引发思考的话题似乎一直变少的趋势。希望园子能少一些做广告的、不明真相的喷子、哗众取宠的营销、只要代码不要思考的小白。也希望大家在学习技术时，从实用和实践出发，从具体的技术的分析中进行更多的思考，得到更多的思想。
其实我们每个人都很容易受影响，这些年估计很多人和我一样，也许没那么多精力和时间，但一直保持着对园子的关注，AJAX、jQuery设计模式、ENTLIB、EF、MVC、面向对象设计、AOP一路的跟过来，虽然有时候只是看一看、想一想。有时候会为自己想明白了某些问题的本质而兴高采烈，希望大家都能一起成长，而不是日复一日的原地踏步，甚至习惯了迷茫。你有一种思想，我有一种思想，我们交换得到两种。想要提高自己，需要多交流，而不是敝帚自珍，因为对于有准备有追求的人，有没有你的帮助他都会前进，而对于思想懒惰的只想伸手要代码的人，你至少整理了自己的思路。这是怎么算都不亏的事。该进步的，肯定会进步，那么大家都多些交流，相比进步的速度也能更快一些。
出处：http://easygame.cnblogs.com
本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利
