突破常规，这样好不好？

搞个工具, 导出所有的注释 这样不就有个集中的比照了?

感谢你的提醒，这个问题值得注意，避免过度设计！

如果你有统一的命名规范、数据库设计、架构设计，那么根据sql建表语句就可以很方便的生成基础的类和配置，最少会是代码量的60%到80%的工作，我做的项目中，经常会用自己写的工具生成这些基础的源代码。

想法挺好，我在项目中也是感觉的ssh架构冗余的东西太多，曾经也打算把架构精简。但是不知道楼主有没有考虑这些问题：架构重新组合后稳定性和负载能力是否受到影响；项目组的其他成员是否能很快适应这种开发模式，会不会导致项目开发周期延长；最后就是不方便将来的维护，每个新加入的新人都要先熟悉你的思想才能工作。
  我认为在做项目的时候不要使用不成熟的框架，特别是没经过实际项目测试的框架。很危险，总会出一些出人意料的事情。

那岂不是脱了裤子放屁……

没猜错应该是给予MDA思想的一套组件，能自动生成Entity,DAO，service甚至配置信息，这样的确很方便，
去掉了重复代码的编写工作，不过公司目前没有这样的组件，用myeclipse自动生成的代码又不够理想。

架构重新组合后稳定性和负载能力是否受到影响---稳定性应该不会受影响，针对dao和service层，只不过做了一层封装而已，和普通SSH架构的最终方法调用入口是一样的，即最终还是调用 DaoSupport或HibernateTemplate类相关的方法。

架构重新组合后稳定性和负载能力是否受到影响--性能上也许会有所提高，因为类数目的减少，Spring管理对象效率应该会有所提高，代码执行效率上机会没什么影响。

项目组的其他成员是否能很快适应这种开发模式--这样开发模式其实和普通SSH架构模式区别不大，只不过相对简便了些，如果以前做过SSH项目的，应该很容易适应。相信能适应这种架构，开发效率会有提升。


最后就是不方便将来的维护 --- 我的想法最终目的是提高效率和可维护性， 针对维护性上，因为类减少了很多，因此需要维护的地方就少了，而主要的维护工作就转移到通用的DAO和Service上了及Action上和配置上，如果通用的DAO和Service能经受得起实际考验，那么维护工作就只在Action和配置上了。

可以，大家有什么好的想法可以随时沟通，欢迎你在JE发消息给我！

恩 用注解 其实挺好的呢 ~

方案二有比方案一强的地方么？