突破常规，这样好不好？

刚到一个新的项目组，项目采用常规的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中写业务代码。



不知道采用方法一好还是方法二好，大家给我点意见吧，
同时针对方法一和方法二，大家感觉有不好的地方和改进意见也说下吧，欢迎板砖！

纸上谈兵，无真相，，，，，，，，，，，，，，，，，，

那就 springside好了。。。

0配置和0配置文件还是有区别的吧。

目前项目已经按想法进展中，
你认为什么地方纸上谈兵了？能不能具体一点？

和SpringSide还是区别比较大呀，
刚刚下载了SpringSide源码，看了下 /SpingSide/examples/mini-web  工程，
里面的有一个HibernateDao<T, PK extends Serializable>的DAO，AuthorityDao，ResourceDao，RoleDao等DAO继承了他，相当于针对每张表，还是有一个对应的DAO，也有相应的Service，之间的依赖通过Annotation注入，
另外我的泛型DAO和HibernateDao<T, PK extends Serializable>也不一样，我是在方法上泛型，类声明没用泛型，bean的依赖关系通过xml来配置，只不过只有一个DAO简化了配置。

是有区别，也许我说的不够完整，我指的0配置，就是0配置文件的意思。

配置文件的目的就是集中管理，使用注释方便是方便，但是分散化了

感觉还是不要滥用注释比较好

十分赞同你的观点，所以现在项目组对注释用的比较谨慎，
目前仅在Entity中用注释，Action跳转和Bean依赖都是用回配置文件。

欢迎大家板砖，已经准备好雨伞了~~~
:P