突破常规，这样好不好？

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



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

评论

55 楼 rubys 2010-04-07  

skyblue1984 写道

aws 写道

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

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

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

这想法不错，能介绍一下你的俱体做法吗？

54 楼 cocoynut 2009-05-22  

第二种想法很好，给我的项目带来了点启发，如果能给出点事例代码片段就好了，地址也可以，先谢谢了！

53 楼 xieke 2009-05-22  

star022 写道

xieke 写道

当然是第二种好了，要想最大化解放 开发人员的工作量，最好还是彻底抛弃 ssh, 在第二种的思想基础上重新架构。

我的两种想法其实本质上都是基于SSH的，如果彻底抛弃 ssh，肯定得自己写框架了，成本高，风险也大，因为自己不见得就能做得比开源框架好，而且没广泛使用的东西，质量不敢保证！

怎么说呢，拿我们公司比方，用自己定制的框架的项目组，开发速度是别的用ssh项目组的3倍，这是在两个项目组都呆过的同事总结的。

通用的东西，由于要考虑的东西太多，总是大而全。过度设计，缓慢。

52 楼 xuzhfa123 2009-05-22  

xieke 写道

当然是第二种好了，要想最大化解放 开发人员的工作量，最好还是彻底抛弃 ssh, 在第二种的思想基础上重新架构。

是好东西就拿来用，要学会拿来主义。当你自己造轮子时，世面上已经有比你设计更优秀的开源框架了。做项目是以盈利为首要目标，世面上有好东西不用，只能是使项目开发成本增加，降低开发效率，给以后维护这个项目的人带来严重负担。当然你是"天才"，那没有办法啦，因为好东西都是出自天才的，同时也为开源事业贡献一份力量。我们也可用用啊，提高我们的开发效率，^_^

51 楼 xuzhfa123 2009-05-22  

star022 写道

chxkyy 写道

第二种方法 ，你的事务怎么处理？

事物通过拦截器在action控制，所以action的命名规范很重要；
所以第二种做法已经明确事物只能放在action，因为对于一些service中不能满足的增加，修改和删除操作，放在action中处理，必须处于同一事物中。

事务不是你想放那层就放那层的，要根据你项目的性质来，这里涉及到系统分析。总而然之，简单就是好，但不要过分简单。

50 楼 star022 2009-05-21  

smilerain 写道

逻辑简单的可以,但复杂的就不行了,因为那个东西就不是DAO.
不过是一个ADOQuery差不多的东西

我想你说的复杂的应该是指一些复杂的查询或有查询或批量修改更新的操作吧，
复杂查询，其实本质上最终还是一些SQL罢了，也许返回结果是什么不能确定而已，这些是有办法解决的；
对于有查询或批量修改更新的操作，本质上是可以分解为一个个基本的DAO操作的，因而业务是可以放在Service层的，如果只有一个BaseService，在业务可以在Action层分解。

49 楼 star022 2009-05-21  

visualcatsharp 写道

用了ssh的话永远都突破不了所谓的常规

我说的常规，进相对于普通做法，本质上是没脱离SSH的。

48 楼 star022 2009-05-21  

xieke 写道

当然是第二种好了，要想最大化解放 开发人员的工作量，最好还是彻底抛弃 ssh, 在第二种的思想基础上重新架构。

我的两种想法其实本质上都是基于SSH的，如果彻底抛弃 ssh，肯定得自己写框架了，成本高，风险也大，因为自己不见得就能做得比开源框架好，而且没广泛使用的东西，质量不敢保证！

47 楼 visualcatsharp 2009-05-21  

用了ssh的话永远都突破不了所谓的常规

46 楼 xieke 2009-05-21  

当然是第二种好了，要想最大化解放 开发人员的工作量，最好还是彻底抛弃 ssh, 在第二种的思想基础上重新架构。

45 楼 jasin2008 2009-05-21  

acition-->delegate-->facade-->command(service)-->dao

44 楼 x_root 2009-05-21  

你的想法一我目前就是这样用的，没什么问题，

43 楼 風一樣的男子 2009-05-21  

可以试 newxy
我朋友公司就用 newxy+struts

42 楼 smilerain 2009-05-21  

逻辑简单的可以,但复杂的就不行了,因为那个东西就不是DAO.
不过是一个ADOQuery差不多的东西

41 楼 lgcpeter 2009-05-21  

最好能把BaseDAO和BaseService的代码公开一下。

40 楼 lnaigg 2009-05-20  

如果是做项目，不考虑需要升级兼容性和扩展性，我觉得没必要考虑那么复杂，经典的设计就足够了，你考虑框架的精力可以省出来理解业务。

老实说，你这种设计只会提高开发人员和实施维护人员的学习曲线，对项目开发效率提高不会太大。

另，我对Annotation也不太感冒，看似很方便，但项目大了不好维护。

39 楼 pipilu 2009-05-20  

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

38 楼 whaosoft 2009-05-20  

恩 用注解 其实挺好的呢 ~

37 楼 star022 2009-05-20  

showtime520 写道

我支持楼主的第二种方案，把DAO尽量压缩，用baseservice类来充当以前的DAO，这样能少很多代码的，现在我的这个项目就是这样，有兴趣可以交流。

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

36 楼 star022 2009-05-20  

yshao81710 写道

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

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

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

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


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