给做快速开发框架的人泼泼凉水

这里我倒是看到了xml和annotation之间有一个代码生成的需求。

annotation最大的好处是，IDE语法检查，重构非常友好。
代码紧凑，同一个事情不必不同文件间反复跳转。

这对开发非常有利。

但是一到实施就麻烦了，不要我改一点配置就重新编译吧。

hibernate 有自己的官方annotation2xml转换工具，其他的呢？webwork，spring这方面有没有工具支持？

用xml还是annotation的关键是，你的配置指定的属性到底是依赖于环境还是依赖于自己
1. xml是用于做外部资源指定的，它会随环境变化而变化。如，用xml指定连接的数据库的属性。
2. annotation是用来指定自身属性的，它只随自身的变化而变化。 如，用annotation指定一个bean是否是serializable。

如果在第一种情况下用annotation，显然有害无益；反之也一样。所以，xml和annotation各有优缺点，各有擅长。一味的用xml或一味的用annotation，都有问题。

我比较赞同楼主的想法。
其实随着业务的复杂化，代码生成器或者所谓快速开发框架越发变得不适用。
与其为了生成所谓快速代码而投入精力，
不如采用简化的结构，在设计和可维护性上下功夫。

lz自己理解的快速开发和现在的快速开发不是一个概念,快速开发不是代码生成,java本身不是脚本语言,不合适搞代码生成,搞配置生成还可行.grails应该是真正意义上的快速开发框架.而楼主的代码生成器,代码一旦静态化之后就有很多问题,包括版本更新等都是不可预见的...所以我觉得本身lz理解上就有偏差,那后面的评价就不置可否了.

大家都在用着快速开发生成的javaeye确又在异口同声的说着ROR不好。呵呵

我不明白的是你为什么会产生改Hibernate配置的需求，我们可以探讨一下你是什么场景需要，至少我认为是不需要的。

其他的类似，我既然说大部分配置是为代码服务的意味着这些配置只要修改，往往就需要修改代码，如果真出现你认为的只改配置不改代码我认为是有问题的。有兴趣我可以深入和你探讨各种细节。

至于实施型配置文件，我也说点具体的：
我认为实施的时候即使是实施型xml也不能随意修改，都应该用ant统一自动修改并打包，这样才能便于测试和发布、版本的跟踪和分支控制，否则都靠人工该配置，很容易失控，或者是由于配置引起的bug而导致回归测试不能重现错误，都是要尽量避免的。

如果是一个独立的项目，修改的可能性是不大，如果作为一个通用的产品这种需求还是会比较常见的，譬如，如我们可能修改一些Spring服务的可选具体实现。hibernate配置的需求更少见一点，但也不能完全排除这种需求，比如对一些缓存参数的设置。可能会更具具体环境做修改。

开玩笑，没有质量，哪来的利润？靠忽悠？

我现在的一个项目的情况如下，一个项目要发布成两个应用，一个对外业务，另一个对内，对外的屏蔽管理员功能，两个应用打包过程都要绑定不同的一些应用服务器相关信息，因为用的是webshphere，再加上发布的最终目标是三个，公司局域网测试服务器，张江公网测试服务器，北京正式上线服务器，三个服务器+2个版本总共6种打包方式，6种打包方式互相之间相关不同的参数有5-10个，全部通过build.properties事先设定，在ant中就是6个任务。而且ant任务不依赖于eclipse，是根据svn复制（相当于cvs的tag）的一个目录，取指定的版本，然后自动编译，修改所有配置参数，再打成war包，全程自动化，测试人员自己就能操作。整个过程大致这样，不需要手工去改什么东西，除非是临时性调试，基本不会碰到，这样发布的版本才能控制好，否则现场支持人员由于自身的失误，改错了一个配置，异地的开发人员是很难高效的查出问题所在的。

如果是通用产品，就更应该用全自动ant的方式，全部自动化，这样复杂度就转变成了ant脚本编程和参数设置，本身也可以放入svn进行版本控制。

好，上面说的是关于配置型参数的解决方案。如果是牵涉到某些业务配置的话，那更多的就是设计上的问题，3种办法：
1.ant脚本在编译之前修改源代码中的注解信息，呵呵，刚刚拍脑袋想出来的，好像也没啥不好的，未经实践论证，感觉理论上也可行啊。
2.像Hibernate的注解和配置是可以同时使用的，把必要信息放在配置文件中，风格和方式不统一，不是很好。
3.设计上事先确定好哪些参数是要随不同的环境或不同的客户需要在ant任务中灵活修改的，这些参数就必须要独立出来，采用配置文件的方式，剩下的就可以认为和实施层面无关的参数，凡是能用注解简化配置的尽量用注解。那这个方法的关键就是“是否是实施参数”的标准，这个标准每个人都不一样了，有人会说某个参数实施的时候可能会变，但是实际情况是这个可能性根本不存在。