为何代码生成器都要这么智能呢?

现在的代码生成器生成的代码文件都会自动插出在我们的项目中,为何不提供一个将生成的文件生成在硬盘某个目录下,再由我们手工copy回来工作区?

这样可以避免开发人员需要考虑文件会不会被覆盖的问题.并且手工的动作很快,也不容易出错.

本人编写了的一个基于数据库的代码生成器,就是要解决上面提到的问题,可以生成Hibernate Model,Dao,Manager,Struts/Struts2 Action,JSP页面(增删改查及列表页面,表单验证),以下为代码生成器相关特性

• 以application方式运行生成器,代码即是配置.
• 将文件系统的目录名称及文件名称作为生成器的一部分,模板文件的的名称与目录名称可以直接引用相关变量,如${basepackage}/${className}.java (${className}=Blog,则会生成Blog.java)
• 以@testExpression结尾的模板文件为有条件忽略,如果testExpression的值在数据模型为true则生成该文件,生成的文件不会包含@testExpression,反之则不生成该文件(应用场景:用于在是否要生成hibernate联合主建的文件中)
• 支持文件插入操作,如模板输出生成的地方已经有该同名的文件存在,并且文件中有包含"webapp-generator-insert-location"标记,则模板生成的内容会插入在该标记之后该特性对如生成的spring配置内容插入spring配置文件十分有用

生成器入口

	public static void main(String[] args) throws Exception {
		Generator g = new Generator();
		
		g.clean();
		g.generateTable("blog");
//		g.generateAllTable();
	}

这里是上一篇[搞不明白],被移至入门区了
[搞不明白]直接在Action中返回forward不好么

搞完了[搞不明白],会发布一个应用开发框架,提供类似rails的基于url确定action访问的零配置快速编程,自带一个代码生成器,已经完成的组合基于struts+spring+hibernate,struts2+spring+hibernate.

不错，我以前也写过一个代码生成器，但是我们老大说，你这一搞，其它程序员就要失业了，我就没有继续搞下去了!

你这一搞，我看不但其它程序员要失业了，国内的软件公司要倒掉一批了。

偶代表这批没有失业的程序员深深地感谢您...

千万不要公开您的代码生成器呀，否则我们都要领失业救济金了

其实，我早就想做一款“代码生成器生成器”了，这样就不会失业了。

呵呵，现在的代码生成器已经智能到了判断是否会覆盖的情况了，如果会覆盖的话会给出提示并显示两个文件的compare视图的，由用户来判断是否覆盖或者将新生成的文件保存到另外的目录去，所以应该不会出现楼主所说的情况了吧

说了这么多.我还是希望能看一看这个代码生成器...
现在公司都是用自己封装的框架.这些代码生成器还有作用吗?

很多开发都可以直接用代码生成器的，其实计算机就是做那些重复的，容易复制的工作，如果程序员天天都在不停的写着90%类似的代码，那才是真的浪费。不过楼主的想法值得讨论，如果生成新代码，说明旧代码已经不再适合了，新的代码代替旧的应该是正常的吧？

旧的代码一般包含很多业务逻辑了,不想被覆盖掉的.
生成器只是一开始生成基础的代码,后面如为hibernate增加字段都是手工添加的.