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

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

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

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

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

     4）程序调试不方便。

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

 

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

评论

115 楼 uptorun 2009-07-29  

dao层次是有必要存在的， 至少可以保证数据库代码的充用与屏蔽 .
大多数的业务层代码比较简单，但是对事物的控制时抽象Service的
重要理由，但是好像没有必要一个实体一个Service，我的做法通常是
一个业务模块一个Service借口.

114 楼 h521999 2009-07-28  

个人认为，应该看项目大小而定，如果项目小的完全可以无需接口。

113 楼 lin23871 2009-07-28  

yangwudong 写道

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

还是那句话：效率怎么保证？

112 楼 lin23871 2009-07-28  

zhenjia 写道

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

那效率呢？比直接操作sql效率地很多，hibernate本身效率就不高！

111 楼 lin23871 2009-07-28  

liuqiang 写道

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

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

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

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

“一个接口可以有多个实现，在大点的项目里这个是很常见的”，举例说明下

110 楼 lin23871 2009-07-28  

downpour 写道

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

什么好处？？请说出来

109 楼 WithMemores 2008-10-21  

个人感觉，层的目标主要是降低复杂性和耦合度。
层粉的多了，每个层需要处理的东西就少了。需求因为接口就抽象起来了，
容易变更和维护。
不过，事实上，因为层的增多，需要抽象的组件越多。代码越多。处理的功能过于集中和局部。不很容易明白整体的处理方式，或者说要求的起点太高。如果在大多数时间做的都是不大的项目。那么使用起来纯属找虐。
对Hibernate的部分观点。Hibernate处理的是数据库解耦。如果不引入DAO接口
要Hibernate干吗？

108 楼 liuwei1981 2008-10-11  

项目不大，功能不复杂的话，感觉像rails一样，设置一个controller放action，一个service放service方法，model放模型类，比较好，如果功能负责，就得按照业务分包了。

107 楼 lxlzhn 2008-10-10  

mingo 写道

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

同意！标准就是用来衡量的，不是用来实际操作的。

106 楼 forever_jenova 2008-10-08  

还是喜欢接口+实现类~

105 楼 lin5061 2008-10-05  

我认为DAO层大多数情况下都有它存在的必要 除非你的业务真的是写一次就定死了 而且业务太简单。原因是：
1.的确hibernate提供了很方便的接口了，而且spring更是将dao操作封装得淋漓尽致，但是当你突然想加一个业务相关的dao方法给许多service用的时候 你咋办呢？
2.框架只需要提供一个DAO即可，这样基本上就只会多出两个文件：一个是DAO接口 一个是DAO实现类。这个实现类继承第三方的就行，比如hibernate或spring提供的。如果再有其它添加方法可以在这里自定义。毕竟你可以这么认为：hibernate和spring所提供的操作基本都是原子性的，如果需要一点点业务色彩的方法就得自己写了（当然这不是业务类。）

104 楼 xyf_84 2008-10-05  

概念不清还在这里讨论

103 楼 laodizhuq 2008-10-04  

适合的就是最好的，如果是大型项目，分层和接口都非常重要。
接口可以更方便的多人合作开发，只要事先吧接口写好，各自就可以写自己的代码，而不用等待别人的代码完成了才可以调试测试。你可以自己写一个简单的接口实现直接返回true，然后来测试自己的代码，不用等待。
对于分成的多少完全要看应用，我们公司的应用还把service层拆开来做两层。因为根据我们的业务需求把所有的业务逻辑都放在一层里面，会导致service层非常庞大，不利于维护，所以我们允许在service层之上再写一层，比如专门控制流程。service层就实现每个节点的功能。

102 楼 summerbell 2008-10-03  

godoo 写道

我做了多年的软件开发，从我的经历来讲讲我的意见，首先，看看你所说的采用接口的缺点吧
1. 创建的文件数量太多－－你做的项目多大，占用了多少开发工作量？请统计一下自己的工作内容和时间，从我的经验看，这个问题几乎可以忽略
2. 增加了开发人员的工作量－－同问题1，如果采用自动生成接口文件，那工作量就更少到忽略了
3. 增加了后期维护的复杂性－－本质同1
4. 程序调试不方便－－有一定道理，但我的情况来看，也不困难；还有些插件可以帮助找到接口的具体实现

优点说个体会最深的
1. 如果你自己写测试（特别是如果你是TDD爱好者），你会体验到接口的威力
2. 接口的确会使你的应用灵活很多；DAO改变实现很少，不管是换DB，还是换框架或实现，业务层换具体实现也不太多，但你测试时会方便很多（这个所有都适用）；
其他优点还有不少，可以参考如敏捷软件开发之类的书籍

1. 如果你自己写测试（特别是如果你是TDD爱好者），你会体验到接口的威力
---------
能具体展开说一下么？

101 楼 z494627 2008-10-02  

分层本来就是为了灵活，使用接口也是为了应付变化。不要说迁移持久层的实现，就是客户的一些临时的需求变化，也会导致程序很多地方变动。软件就是要应付变化！

100 楼 williamou 2008-09-30  

guoping007 写道

mingo 写道

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

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

很同意楼上的说法。。
要不要分层，分多少层应该以项目的具体情况而定

99 楼 xugq035 2008-09-30  

接口还是需要的，为什么一定要区分大项目和小项目？小项目随着需求的不断增加和修改也会转化成大项目，除非你认为自己做出来的应用没有进步的意义。
dao一般是一个表对应一个，当然也存在操作多个表或者直接执行原生sql；service通常是调用多个dao去处理事务，并不是一个service只能调用一个dao
我现在的做法是action中既调用service也调用dao，一些简单的查询直接调用dao就可以执行，没必要在service中重复一次；一些复杂的事务或者可能在多个action中都调用的方法都放在service中实现

98 楼 wopenonline111 2008-09-29  

downpour 写道

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

强烈怀疑在小项目中使用接口所带来的好处，5，6万行规模的项目使用接口恐怕带来的收益不能抵消其所增加的成本。

97 楼 neptune 2008-09-29  

在做项目时，问心自问，你的Service接口有几个实现，你的Dao接口有几个实现。分层是必要的，但每个Service和Dao都只有其对应的，一个Interface和一个Implement，那还有意义吗

96 楼 wzybadboy 2008-09-28  

个人觉得应该有dao和service，接口也是必要的，首先是从面向接口编程的角度来讲，其次接口可以去掉重复的代码，降低代码的耦合度。像上面说的可以在service层调用dao侧的实现方法，也不会增加太多的代码量，实现的代码结构清晰，耦合度低。