突破常规，这样好不好？
刚到一个新的项目组，项目采用常规的SSH架构，还处于初期阶段。项目分层是：
JSP-->Action-->Service-->DAO--->Entity--->DB Table
一般情况是一张表或视图，往往会对应一个Entity，然后针对这个Entity会有一个DAO Bean来维护，DAO也会有一个相应的Service Bean，最后由Action来调用。这样一来，似乎很麻烦，因为我们还需要做很多事情：
1.Entity映射，一张表需要一个hbm.xml文件；
2.在Hibernate配置文件中注入需要维护的Entity 所有hbm.xml文件；
3.在Spring中配置DAO Bean;
4.在Spring中配置Service Bean，同时还需要配置引用的DAO ref;
剩下就是Action Bean及调整配置了；
鉴于此，很多地方配置改用Annotation方式，比如Entity与表的关联，属性与表字段关联，DAO和Service也采用Annotation，甚至连struts2的调整也用Annotation...，似乎感觉到Annotation的泛滥了，这样的确是方便了很多，甚至可以0配置；但也带来了问题，导致没有一个全局性的文件来查看页面流程跳转，业务组件的依赖，感觉项目的可维护性变差；
因此决定对其做一定的改造，Entity用Annotation，用packageToScan简化配置，针对Service和DAO层，则有如下种想法，
想法一：
1.整个项目只采用一个泛型DAO， 泛型机制只用于方法，因此有别于BaseDAO<T, PK extends Serializable>这样的DAO。这样的DAO已经写好，支持简单的CRUD及复杂查询，包括自定义查询（结果返回可自定义）；
2.再些一个通用的BaseService组件，注入BaseDAO，提供常规的CRUD方法，作为父类；然后其他业务类直接继承即可；
优点：1.不需要做繁琐的DAO Bean配置，因为只有一个BaseDAO，仅配置一次即可；
2.针对Service Bean也仅需做简单的配置，而无需配置DAO ref(因为在父类已注入)；
这样一来，代码量和配置大大减轻。
缺点：还是需要为为一个Service Bean做配置。
想法二：
1.整个项目只采用一个泛型DAO；
2.提供一个强大的BaseService，重写Struts Action父类，将BaseService注入，推荐项目组只用这一个BaseService，不建议项目组为每个业务对象写一个类；如果有BaseService不能满足的，就在action中提供一个private来方法，封装业务。
优点：1.服务层类会大大减少，一定程度上减少代码量，同时更简化了服务层配置；
2.action的配置也简化，不需要为每个action配置Service的ref，因为已经重写父类，在父类中已注入;
缺点: action中代码量会有所增加，因为有些BaseService不能提供的，需要在action中写业务代码。
不知道采用方法一好还是方法二好，大家给我点意见吧，
同时针对方法一和方法二，大家感觉有不好的地方和改进意见也说下吧，欢迎板砖！
50 楼 star022 2009-05-21 smilerain 写道逻辑简单的可以,但复杂的就不行了,因为那个东西就不是DAO.
不过是一个ADOQuery差不多的东西
我想你说的复杂的应该是指一些复杂的查询或有查询或批量修改更新的操作吧，
复杂查询，其实本质上最终还是一些SQL罢了，也许返回结果是什么不能确定而已，这些是有办法解决的；
对于有查询或批量修改更新的操作，本质上是可以分解为一个个基本的DAO操作的，因而业务是可以放在Service层的，如果只有一个BaseService，在业务可以在Action层分解。
51 楼 xuzhfa123 2009-05-22 star022 写道chxkyy 写道第二种方法 ，你的事务怎么处理？
事物通过拦截器在action控制，所以action的命名规范很重要；
所以第二种做法已经明确事物只能放在action，因为对于一些service中不能满足的增加，修改和删除操作，放在action中处理，必须处于同一事物中。
事务不是你想放那层就放那层的，要根据你项目的性质来，这里涉及到系统分析。总而然之，简单就是好，但不要过分简单。 52 楼 xuzhfa123 2009-05-22 xieke 写道当然是第二种好了，要想最大化解放 开发人员的工作量，最好还是彻底抛弃 ssh, 在第二种的思想基础上重新架构。
是好东西就拿来用，要学会拿来主义。当你自己造轮子时，世面上已经有比你设计更优秀的开源框架了。做项目是以盈利为首要目标，世面上有好东西不用，只能是使项目开发成本增加，降低开发效率，给以后维护这个项目的人带来严重负担。当然你是"天才"，那没有办法啦，因为好东西都是出自天才的，同时也为开源事业贡献一份力量。我们也可用用啊，提高我们的开发效率，^_^ 53 楼 xieke 2009-05-22 star022 写道xieke 写道当然是第二种好了，要想最大化解放 开发人员的工作量，最好还是彻底抛弃 ssh, 在第二种的思想基础上重新架构。
我的两种想法其实本质上都是基于SSH的，如果彻底抛弃 ssh，肯定得自己写框架了，成本高，风险也大，因为自己不见得就能做得比开源框架好，而且没广泛使用的东西，质量不敢保证！
怎么说呢，拿我们公司比方，用自己定制的框架的项目组，开发速度是别的用ssh项目组的3倍，这是在两个项目组都呆过的同事总结的。
通用的东西，由于要考虑的东西太多，总是大而全。过度设计，缓慢。 54 楼 cocoynut 2009-05-22 第二种想法很好，给我的项目带来了点启发，如果能给出点事例代码片段就好了，地址也可以，先谢谢了！ 55 楼 rubys 2010-04-07 skyblue1984 写道aws 写道配置文件的目的就是集中管理，使用注释方便是方便，但是分散化了
感觉还是不要滥用注释比较好
搞个工具, 导出所有的注释 这样不就有个集中的比照了?
这想法不错，能介绍一下你的俱体做法吗？
