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

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

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

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

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

     4）程序调试不方便。

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

 

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

评论

35 楼 rola 2008-09-23  

我是觉得，分成Action，Service，Dao的思想的主要原因是DAO主要完成单表的一些增，删，改，主要给Service调用（重用了），Service代表着业务操作，Facade就是在这里起作用，更重要的是，事务必须起停在业务操作中

34 楼 rola 2008-09-23  

确实，Action+Service+Dao让人难受，如果有增加功能接口的话，上上下下都得改，针对比较简单的项目，我会把Service+Dao合并，就让Mmodel和Controler用一个类来实现，中间辅以业务接口，也能体现MVC的思想！
如今看看Seam，确实受启发，连Entity都可以充当VO了，那么SessionBean完成Model+Controler的功能也就能接受

33 楼 ztka 2008-09-23  

chen-516888 写道

.................
Spring AOP对接口的动态代理类是通过Java Reflection 生成的
如果只是对类生成动态代理类,则使用CGLIB,效率稍微会低一些.

接口和实现分开是为了实现抽象化和实现的分离,使得实现可以动态的改变
你的应用中不需要考虑这样的问题,不代表这样不好

至于能不能"去掉",视具体情况而定吧.完全的话...个人觉得太绝对了

你的DAOImpl如果是基于MySQL和一些特有的东西,有一天你的系统数据库
迁移到Oracle,并且使用了Oracle的一些特性,只需要实现新的DAOImpl代替
原来的DAOImpl就可以了.如果没有接口和实现的分离,就很麻烦了,
可能需要大量修改业务层的代码.
个人拙见

太理想化了，一般来说从mysql迁移到oracle，改动的比这个多的多，基本和数据库打交道的都要重写。

32 楼 mycybyb 2008-09-23  

chen-516888 写道

.................
Spring AOP对接口的动态代理类是通过Java Reflection 生成的
如果只是对类生成动态代理类,则使用CGLIB,效率稍微会低一些.

接口和实现分开是为了实现抽象化和实现的分离,使得实现可以动态的改变
你的应用中不需要考虑这样的问题,不代表这样不好

至于能不能"去掉",视具体情况而定吧.完全的话...个人觉得太绝对了

你的DAOImpl如果是基于MySQL和一些特有的东西,有一天你的系统数据库
迁移到Oracle,并且使用了Oracle的一些特性,只需要实现新的DAOImpl代替
原来的DAOImpl就可以了.如果没有接口和实现的分离,就很麻烦了,
可能需要大量修改业务层的代码.
个人拙见

请问，这个DAOImpl在整个系统中是不是只有一个。还是像楼主的图中那样，一个service对应一个dao？谢谢。

31 楼 mycybyb 2008-09-23  

fish2007 写道

  DAO层为什么作为可选层呢? 你把对数据库的访问和逻辑的处理都放在service层， 不觉得很乱吗。
  对于接口，DAO层的接口，我觉得是可选的，但是service层的接口还是有必要的。在项目中，有很多不期而遇的变化，当你使用了接口，那么你的实现类的变化，就不会对外界产生任何影响。

处理逻辑应该放在service层吧。
访问数据应该放在DAO层，但访问什么样的数据还是应该有service决定吧，DAO应该只是执行而已，并对执行结果进行一定的转换。这样DAO整个系统就只有一个啊，不需要每个service都对应一个DAO。而且这一个DAO对外提供的是一个接口，具体内部是用JDBC还是hibernate，service不需要关心。

30 楼 simonli 2008-09-23  

我同意楼主的观点。简单就好

29 楼 fish2007 2008-09-23  

  DAO层为什么作为可选层呢? 你把对数据库的访问和逻辑的处理都放在service层， 不觉得很乱吗。
  对于接口，DAO层的接口，我觉得是可选的，但是service层的接口还是有必要的。在项目中，有很多不期而遇的变化，当你使用了接口，那么你的实现类的变化，就不会对外界产生任何影响。

28 楼 java55 2008-09-23  

CALM 写道

ltian 写道

要是框架做的好，绝大多数情况下，Dao层只需要接口，不需要写实现类。做到不到这点，说明公司里面的构架师还需进一步努力。

没看明白，能详细讲讲么，怎么个不写实现类啊？

其实就是所有的实现都在框架的某个最高层的类中实现了增删改查的操作，然后以后的所有的dao实现只要extend就可以了，而不需要每次都重新再写实现了

27 楼 melode11 2008-09-23  

yangwudong 写道

低耦合，高复用
就这六个字，足够解释的了

那就解释解释纯粹的接口抽取，复用高在哪里？

26 楼 freej 2008-09-23  

简单说两句：

我认为，在满足项目本身灵活性要求的前提下，分层或者说继承要尽量的少。分清职责，多用组合。这样才能使系统更加清晰，维护更加方便。

25 楼 yangwudong 2008-09-23  

低耦合，高复用
就这六个字，足够解释的了

24 楼 fastzch 2008-09-23  

<div class='quote_title'>raymond.chen 写道</div>
<div class='quote_div'>其实，Service层和Dao层的接口文件完全可以去掉的</div>
<p><br/>同意这个。</p>

23 楼 CALM 2008-09-23  

ltian 写道

要是框架做的好，绝大多数情况下，Dao层只需要接口，不需要写实现类。做到不到这点，说明公司里面的构架师还需进一步努力。

没看明白，能详细讲讲么，怎么个不写实现类啊？

22 楼 withoutmewang 2008-09-22  

增加了开发和维护负担？ 增加了多少？ 跟spring有关？
为啥不只写jsp呢，那样文件最少了!

可测试性是个非常重要的衡量因素

21 楼 kaka2008 2008-09-22  

抛出异常的爱 写道

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

恩恩，有收获

20 楼 zean 2008-09-22  

同意LZ的看法，我们项目也有这样的毛病，归根结底是太过教条、对接口认识的不足，这样的接口实际上毫无意义，增加了开发和维护负担。

19 楼 DaemonChen 2008-09-22  

分层还是有必要的。对于团队来说。可以明确目标与任务。至于要不要DAO层，还是要看项目大小与开发周期。接口的作用在于定义规范，可移植性也会提高。实现也会更加灵活。

18 楼 nwangwei 2008-09-22  

用Hibernate，基本上大小项目都不需要DAO层了

17 楼 zhenjia 2008-09-22  

你给我的感觉就是觉得service 和dao 没必要同时存在，没必要去对应那些接口。
dao,和数据直接打交道
service,通过dao实现业务逻辑
你可直接实现动态dao
那样的话你就只剩下service了
http://www.iteye.com/topic/232885类似我实现的这样

16 楼 fenxue 2008-09-22  

但是，我现在做过的几个项目来看，接口定义是非常有必要的，以后有需要重构的地方，运用比较好的设计模式，就会让你受益的。