在项目架构中如何进行分层才是最合理的？

     目前很多项目在框架搭建时都遵循以下的分层关系：View层、Action层、Service层、Dao层。在Service层和Dao层中，一个接口文件对应一个实现类，无论是大项目还是小项目，都按照这个模式去做，说这是软件架构的标准做法。本人觉得，一个接口文件对应一个实现类这样做有很多缺点：

     1）创建的文件数量太多。

     2）增加了开发人员的工作量。

     3）增加了后期维护的复杂性。

     4）程序调试不方便。

其实，Service层和Dao层的接口文件完全可以去掉的，只需要具体类就可以了，而且Dao层也不是必须的，可以作为可选层来处理。当Service层的一些方法需要在多个地方引用时，才增加Dao层，用于存放这些公共方法。

 

     SpringSide就是这样做的，不知道大家的看法如何？

评论

15 楼 fenxue 2008-09-22  

1.其实service层接口还是有必要，有一种情况：以后的系统要移植到spring中，然后在service层加入事务控制。
2.楼主所说的view层和action层其实就是view层了，如果有能力的话，控制器可以做几个就够了，比如一般业务一个，工作流一个，用户登陆一个.....
3.如果现系统中没有spring管理事务，刚事务控制可以放在action中，如果有发生延迟加载的话，可以放在过滤器控制，这样子也挺好的。
4.DAO层和services层有的时候可以结合在一起，就是上述情况，事务控制不在services层中进行。

14 楼 raymond2006k 2008-09-22  

   同意楼主。虽然我们项目中用了 “接口+实现” 的模式的Service， 但就轻量级开发，我觉得也没必要存在Service接口；按功能建立的DAO接口更没有必要了。 100个功能，就多了200个Java文件，文件数太多了。

13 楼 抛出异常的爱 2008-09-22  

liuqiang 写道

据我的理解，分层的好处在于：

1 团队协作，一个组负责一个层，一个人负责该层的若干个点

2 可扩展性，一个接口可以有多个实现，在大点的项目里这个是很常见的，对于中小型的web来说，还是php rails来的爽

3 可维护性，哪个层出了问题就去哪个层解决

1.分层目的:
dao与service是为了区别事务的边界.
(这样是为了让 spring 更好的区分)
action以上分成一层是由于struts不好测试,所以很多页面的跳转是不做测试的.
(我们的项目是struts1.0)


2我认为接口是用来写注释的地方
对于程序来说越短越好,但接口就可以写很多.
可以把你的需求定义,用例都写到接口里面.

PS:楼上...如果你的业务不变化.那么结构化编程会更好理解一些.

12 楼 chenjianjx 2008-09-22  

我的看法：

  1.如果是用hibernate，可以不用DAO

  2.的确没有必要在每个功能上都用 一个接口 + 一个类 的套子来自虐。
       a.我们做的不是框架，而是具体的应用，在service这里不需要过多考虑灵活性，DAO就更加不需要了，因为更换持久层框架的事情不太可能发生
       b.用接口+类写成的代码，看起来非常累。尤其是想看一个功能的实现时，要很费劲才能找到接口对应的实现类，然后还要在实现类中费劲地找到具体的Method

  3.其实Service层也可以考虑重用－－将可重用的业务逻辑定义为XxxService，将具体的，直接对应于USE CASE的功能定义为XxxApplication -- 这就是Core J2EE Partterns中的Application Layer模式
      

11 楼 liuqiang 2008-09-22  

据我的理解，分层的好处在于：

1 团队协作，一个组负责一个层，一个人负责该层的若干个点

2 可扩展性，一个接口可以有多个实现，在大点的项目里这个是很常见的，对于中小型的web来说，还是php rails来的爽

3 可维护性，哪个层出了问题就去哪个层解决

10 楼 tibetjungle 2008-09-22  

分这么多层还是有必要的吧，而且针对接口编程是行业的best practice，还是遵守的好。对于无法预期的变化，这种做法会带来好处。比如dao实现真由hibernate变为ibatis，接口所能带来的好处就显而易见。

另外是成本问题，感觉增加一个接口并不会提升多少开发的成本，因为在实现类中，什么方法名你还是要书写的。

9 楼 mycybyb 2008-09-22  

我觉得应该是在service中调用dao的save方法，但dao只是一个具体的类。只是处理与数据库有关的事情，就是增删改查。业务相关的放到service。

8 楼 kenken0y 2008-09-22  

我们现在Service是从dao继承的,但是做到一定程度的时候我觉得还是分开比较好,
比如说:service和dao中都有save方法,但是语义是不同的,service中需要处理相关的内容,但是dao中不需要,从这个角度来说,可以service先从一个通用dao继承,省去dao层,需要的时候再慢慢丰富

如果使用aop的话还是要接口的,可以先不写接口,等要用的时候再提取出来

总之,尽量推迟成本的付出,但必须付出的成本一定不要省

7 楼 mycybyb 2008-09-22  

个人觉得DAO完全没有存在的必要

6 楼 eveil 2008-09-21  

项目不大，并且业务逻辑相对来说比较简单，感觉没必要！

5 楼 melode11 2008-09-21  

service用接口主要是为了配置spring 声明式事务。
而如果你的的dao不会有很大的变化的话，可以不需要接口。
如果某天你需要要准备两种类型dao（比如一种hibernate，一种ibatis的）随时切换，面向接口编程可以带来一点方便，不过这种情况不多，所以我也一般不提取DAO的接口。

4 楼 srdrm 2008-09-21  

适当做调整
service 层可以按模块去划分。而不必一个实体一个service

dao 可以这么干

3 楼 downpour 2008-09-21  

在任何时候，请使用面向接口的编程方式，尤其在项目不断膨胀的过程中，针对接口的编程会为你带来无穷的好处。

2 楼 guoping007 2008-09-21  

mingo 写道

适合的就是最好的。标准做法只能说是参考。

就我个人理解，作三层的目的最大的作用是消除重复代码，同时使项目更容易理解和扩展，当然也有很多教科书的说法，比如说移植性，但实际上真正有用的就是消除重复代码。
  另外对于接口的看法，看项目了，如果项目较小，不用接口没什么影响，如果项目比较复杂，接口还是能带来很多好处的。

1 楼 mingo 2008-09-21  

适合的就是最好的。标准做法只能说是参考。