从4.0工程中的开发工具想到，开发一个代码生成工具。http://www.openlab.net.cn/forums/posts/1684421.aspx

 

结果google以下，发现这个咚咚：

http://blog.csdn.net/dingbaosheng/archive/2007/01/02/1472387.aspx

哎，感叹！

这种东西很常见。
Ruby On Rails里面，Domain设计好，关系定好，敲行命令，从CRUD页面到程序骨架到数据库schema,啥都出来了。
Groovy，Python，PHP里，现在也有类似的东西。

当然，我不认为这些东西是必须的。

广告呀广告。

基于模板。



灵活性，才能带来创造。

（1）离线设计数据库，保存成xml语言。
（2）根据设置的数据连接字符串，连接数据库，创建数据库和基础数据，数据库可以是ms或mysql等。
（3）根据模板生成对应的 sql脚本、实体类、数据接口代码等。（得有个好的模板引擎）
（4）能够生成vs或其他工程文件。

.NET里我不知道，就你这四点，我说说自己的一些体会吧

1）离线设计数据库，保存成xml语言。
在Java里，早年的iBatis就是如此。现在一般新系统，都使用ORM，面向对象设计Model，数据库建模自动化。
RoR，Grails，Django,走得更远。

2）根据设置的数据连接字符串，连接数据库，创建数据库和基础数据，数据库可以是ms或mysql等。
Java Hibernate，很久之前就做到数据库兼容，Oracle，MySQL，SQLServer...这个兼容，看你的设计哲学，如果是做项目，这方面的需求实在是有限。

3）根据模板生成对应的 sql脚本、实体类、数据接口代码等。（得有个好的模板引擎）
建议去看一下iBatis, 更建议你去看一下RoR的Active Recorder

4）能够生成vs或其他工程文件。
关注一下Maven，我的所有的工程，就是以这个Build工具来管理的。

但是你用.NET,开发工具肯定是VS，不像Java或其他语言，有那么多IDE（而且普遍不强大）

当然，更进一步，可以关注一下RoR，Grails，Appfuse

 

可能是微软太强势的缘故，让.NET的开源社区，显得太弱小了。其实微软是扮演“引领者的角色”，当然，微软新出来的.NET MVC, LinQ这些东西，配合上VS这套强大的开发工具，还是很有杀伤力的。

1）做项目设计数据库在先，使用数据库在后更加符合行为逻辑。面向对象的设计，数据库建模自动化是正向的过程，逆向呢？ORM的问题在与灵活性受限制，于是智能化不高。RoR，Grails，Django不管走多远，中间件再好，不采用模板+脚本，也是局限于一定的架构和编程模式，只能解决有限集中的问题。
2）数据库兼容是基础，Hibernate对数据库兼容是不错，但是对开发语言呢？为了面向c#还是需要有人开发NHibernate 。怎样能对开发语言兼容呢？
3）Active Record是一个不错的思想，封装了数据访问的衍射。当然，为了要让更多的开发者享受这个成果，同样需要兼容不同语言，或面向不同语言开发对应的版本。还有个问题，就是为了实现这个效果，硬生生在中间加了一层衍射，还搞到了运行时，为什么不能在编译期间呢？Active Record为什么不能Active GetCode然后再编译呢？
4）能够生成vs等类型的工程文件。是指将自动生成的文件+对应工具的工程文件，方便开发，而不需要生成文件后，再打开开发工具-->新建空工程-->导入生成文件。与你用什么项目管理软件没有太大关系。

.NET MVC, LinQ这些东西，包括你提到的NHibernate、iBatis，以及各种ORM这些东西，与代码生成工具还不是一回事。代码生成工具就是工具，生成代码使用的工具。其他各类框架，是实现了某种功能的中间件。也可以用代码生成，生成包含有中间件的工程。

也就是说遇到这样场合：
1.项目刚开始设计和开发之初，数据库类型不明确，数据库结构不成熟。
2.维护项目，对项目关联的数据库结构进行调整。
3.或因某种原因，迁移数据库，更换数据库平台。
……
聪明的程序员都很懒惰，为了减轻以后的负担，于是有两种选择：
1.选择好的框架，能够适应数据库的结构调整、平台的改变。于是便有了ORM类的东西，更聪明的做了Active Record，更加方便灵活运用了。可惜选择一个框架，就得接受它的限制条件。它并不是什么语言都可以用的、不是什么开发工具都可以用的、某个或某种sql语句执行起来还是不行的，等等。做为开发者要么等，要么接受它、适应它。
2.用代码生成工具，生成熟悉的编程语言、熟悉的开发工具识别的工程文件、熟悉的框架结构 的项目，需要做的就是将代码写到脚本中。
不同的解决问题思路而已，只是我觉得后一种方式更好些，也能生成前一种解决方式。

不仅仅是数据库工程，因数据库结构维护才需要用到代码生成工具，还有别的场合：
1.重复、呆板的代码在许多地方使用到，可以编写脚本生成。
2.以前或别的地方用的不错的工程项目框架，引入到新的工程，只要改动少量地方的时候。
3.运行时，需要动态加载的，如游戏后期制作的脚本等等，用脚本生成脚本。

1） 做项目，我一般喜欢用OOAD的方式来考虑问题（当然，报表一类的项目不适合）。UML的类图出来之后，然后再根据这个实现数据库Schema设计。我是Martin 的信徒，在我看来，Rich Domain Object完全适合业务复杂的系统。既然选择了Rich Domain Object，那么ORM几乎是天然的选择。Hibernate在维护实体对象关系的成熟性和智能性上，已经走得很远了--如果你做过两年以上的Hibernate项目，基本通读其源代码的话。

另外，我举的这些解决方案，只是在其固有优势的领域才能发挥效用。另外，RoR，Grails这些Full Stack的动态语言框架，本身就是模板+脚本+约定重于配置。

Domain到Schema，可以实现。Schema到Domain呢？这个么，Java里，现在很多IDE都能做到了。MyEclipse，Netbeans。但是代码质量么...我没见过自动代码生成工具能够生成心目中高质量代码。

是的，任何一种解决方案，几乎天然地只能适应有限的应用领域。那么我再举一条关于企业开发的名言：“没有银弹！”

 

2）对开发语言的兼容，这是个伪命题。Hibernate根植于Java社区（NHibernate不做讨论），RoR根植于Ruby社区，Django来自Python社区。不同的语言社区，不同的社区文化，不同的技术引导着，必然会产生不同的解决方案。我做Java，但是我不会有有色眼镜去看待其他社区的优秀方案，相反，我会去读，去尝试着用，去思考其独特的优势。世界上没有一统天下的开发语言，自然也没有一统天下的解决方案---为什么要语言兼容呢？就算是.NET平台，我也可以很负责任地说，C#开发人员占多数。VB.NET呢？J#呢？Delphi.NET呢？JScript.NET呢？各自的比例是多少呢？你会容忍你的团队里，有人用C#，有人用J#，还有人用VB.NET么？

 

3）Active Record，这个RoR中的ORM层，来自于Martin Flower的企业设计模式。个人认为，Ruby这种弱类型的动态语言，对于实现Active Record有着天生的优势。我曾见过形形色色的Java代码模仿Active Record--(我也曾这么尝试过)，但是很遗憾，静态类型编译型语言，为了让Domain对象变得像Ruby Class那么动态（运行时加入熟悉，注入方法，注入上下文），代码变得异常丑陋。我不得不让我所有的Model都继承一个封装了数据库操作的超类，代码难以测试。

你想要在编译时实现Active Record，或者说，编译前自动Get Code在生成代码再编译.这是个有些有趣的主意。那么请问，你的编译之后的代码，如何Debug？源代码里的那个干净漂亮的Model，都不是一个东西

了。或者说，你原来那个漂亮干净的model,现在被掺和进去了一堆自动生成的代码，变得臃肿不堪？

当然，我很期待看一下C#实现的Active GetCode来实现某种形式上的Active Record。

 

另外，很多重复，呆板的代码，可以通过重构来优化，或者通过IDE的自动生成机制来实现。

总结：你说的那些主意，在某些时候，某些项目，是有意义的。但具备多大的普遍性和必要性，则是另外一回事儿

 

 

几天没有上网,文档回复的很快啊.有探讨才有思考。

我觉得我们之间有几点认识上理解有偏差:

1. 代码生成能力与纯粹的代码生成工具的区别: 中间件或某种框架都提供了代码生成能力;但算不上代码生成工具。 代码生成工具根据固定模板生成对应的代码，更有支持脚本分析的，能够编程实现更多方式的代码生成；生成代码质量高低与脚本的编写出的模板有直接关系。

2. 代码生成与 OOAD方式以及各类可视化设计的区别：可视化设计工具直观、友好、方便、快捷……；代码生成能力应该是可视化工具的一部分，否则可视化没有落脚点；代码生成工具则是支持更加宽泛的、灵活的生成机制。策略与应用需求不一样。

3. 代码生成工具与中间件或框架的区别： 中间件或框架学习使用后，是项目的组成部分，编译、执行都需要。代码生成工具是工具层面的，用来生成代码，更可以生成指定框架或中间件的代码。

4. 代码生成工具对多语言或多框架的支持的认识：针对一个团队或一个人，而得出无价值论比较牵强。代码生成工具特性是与语言无关的。不会因为一个人、一个团队理解掌握的语言、框架、中间件有限而没有价值，对多语言和多框架的支持是面向社会体现价值。就拿一个团队应用Hibernate若干年来举例，熟悉、精通它的每一处源代码，知道发生问题怎么修改都一个人或一个团队的技术实力问题。但是用代码生成工具生成规范的Hibernate框架代码，而且与数据库结构相对应的地方都能够自动生成，不需要再修改配置，是大大提高工作效率。如果这个团队经多一定时期应用后，生成代码的脚本更加完善，以后类似项目的启动和快速开发以及维护都将变得轻松简单。而且更加有趣的是，如果这个团队能够公开这个脚本，配上说明，对于其他个人或团队学习和应用Hibernate解决问题都将有所帮助。同理，对于应用其他框架或中间件，都类似；还有对于代码规范都有很好的促进作用。作用还不仅仅于此。

5. 自动生成代码的可控性：你也认识到目前具有代码生成能力的，并不能生成你心目中的高质量代码。正是各类具备自动生成代码能力的各类工具，只能生成特定格式或按特定方式生成代码，造成自动生成的代码的局限性，不得不再修改以适应特定场景，或改动后自动生成代码不能覆盖，或自动生成代码包含有已知的问题等等；脚本解析类的代码生成工具则是完全可控的，至少可以解决这类问题。你可以把你认为质量比较高的代码文件、代码框架变成脚本或模板。

晚上继续讨论，先Mark