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

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

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

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

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

     4）程序调试不方便。

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

 

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

评论

95 楼 Ethan 2008-09-28  

在软件的结构中应该严格按照层次的划分来组建，不能因为个人觉得有些小麻烦就轻易去掉，这样会个以后的维护以及扩展造成麻烦。但是在分层的时候并不是按照什么view、action、service..等等，而是按照J2ee的层次，上层可以访问下层，顺序不可逆！

94 楼 SpiritRood 2008-09-28  

现大多项目都是SSH框架的,其实在这个体系中Hibernate或者其他的持久层框架都帮助我们实现了DAO层,我们所谓的DAO层其实只是DAO层的业务简单操作的封装层,但是我要提醒的是系统中各个模块之间的业务不同,如果没有这么一层封装的话,会给系统带来很大的不便,比如:你可能就要将这部分代码写入Transaction事务层(就是这里所说的service层),那么在以后的业务变动时,就要将数据操作和事务一起更改,看起来非常混乱和繁琐,带来很大的不便.面对模块划分和单元测试就显得更加繁琐.
面向接口编程其实这是一个很不错的设计理念,可以使设计者不用关心实现,这是最初需要解决的问题所衍生出来的设计理念.
但是现在他同时解决了DAO实现手段变更的不便,当你的实现手段需要变更时,你可以不用担心其他层的变动,比:Action,Service,View...,你可能只需要修改你需要变动的那层代码,同时不用担心会漏掉某些方法或者错误实现.这样也就更发挥了Spring的粘合作用.
对于需求变更,我们无法准确的预计,只能尽可能的防范和提供灵活的实现才能将项目做的灵活方便.

93 楼 qiuhaitao 2008-09-28  

在开始是面向过程的变成，后来演变成面向对象的变成，但现在是面向接口的编程，使用接口可以让任务更好的分配，可是实现横向分配任务，减少程序员的压力。在个人认为Dao层时必须的

92 楼 linhang227 2008-09-27  

俺觉得还是分层好，如果熟练的开发人员，分层的代码其实也不会带来多少工作量。

91 楼 czx566 2008-09-27  

“在Service层和Dao层中，一个接口文件对应一个实现类”完全没有必要！

这个是架构没做好，和用不用接口无关。

90 楼 hotjava 2008-09-27  

我觉得分层的粒度是和系统业务的负责度和不确定行相关的。
如果一个简单的系统业务也不会有太多变化，那别分那么多层简直是受罪。
对于比如说超过100个人月的系统来说，分层不清，职责不明，对外围系统支持多变的情况是非常恐怖的。

89 楼 hotjava 2008-09-27  

分层我的理解就是：

1。事务隔离级别
2。业务层的扩展
3。对外围系统的接口形式和内容的扩展

88 楼 goodfifa07 2008-09-27  

ltian 写道

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

举个例子说明一下

87 楼 shaoyx 2008-09-27  

具体情况具体分析，对于小项目，我觉得lz说的很对。

86 楼 melode11 2008-09-27  

aidiyuxin 写道

接口是针对扩展而言的
如果确定不要扩展
可以采用xp的做法
class == interface
抛弃接口
但是，如果这样，你的软件就不回遵循open-close原则
这表示你要扩展，就要付出昂贵的代价

同意。
因为我觉得很少有要彻底更改DAO这个级别上的实现这种情况。
更改的原因都是出自客户的需求，而客户要的只是一个最终效果。
哪天遇到说周一三五用hibernate，二四六又要你换成JDBC的客户，也是你的运气太好了。

85 楼 tantec 2008-09-27  

<div class='quote_title'>downpour 写道</div>
<div class='quote_div'><span style='color: #ff0000;'>在任何时候，请使用面向接口的编程方式，尤其在项目不断膨胀的过程中，针对接口的编程会为你带来无穷的好处。</span></div>
<p> </p>
<p>同意downpour。你做的项目可能很小，在我做的项目中，基本上都是面向接口编程。感觉真的很好，而且项目多了，用同一个模式开发起来也快，维护起来更加方便，因为是同一个模式。</p>

84 楼 aidiyuxin 2008-09-27  

接口是针对扩展而言的
如果确定不要扩展
可以采用xp的做法
class == interface
抛弃接口
但是，如果这样，你的软件就不回遵循open-close原则
这表示你要扩展，就要付出昂贵的代价

83 楼 tibetjungle 2008-09-27  

melode11 写道

tibetjungle 写道

melode11 写道

godoo 写道

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

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

测试我写的不多，不过我想写测试要替换一个伪DAO的话，使用匿名内部类也能实现这个目的。

用接口最不方便的地方不是要多些这些接口文件，是本来如Eclipse这种IDE可以用Ctrl+点源码，从Service中写的DAO类名直接找到DAO类，用了接口，就必须得自己手工打开这些实现类。
要有修改，也必须得两个文件一起改，真是不胜其烦，感觉这种直接提取所有方法组成Interface的做法，是对Interface功用的扭曲。

Eclipse中早就有插件，可以直接跳转到接口的实现类。

接口定义好后需要不停地修改吗？如果需要，那是设计有问题，没有谁隔三叉五地去修改接口的参数。

另外，个人觉得还是没有必要一个service一个dao，dao是为service服务的，一个service可以调用多个dao，一个dao也可以为多个service服务，到底一个service要多少dao，这要看dao设计的粒度。

只有实现类跳到接口,哪有接口跳到实现类?古板的web项目和很多产品类项目又不同，模块无数多，互相关系却不大，谁有空靠YY就能把需要的接口给写全了，都是按需增加的。
说就事论事嘛，总是要牵扯到设计上去，CRUD项目需要这么多设计么？

不必要一个service一个dao倒没错，哪有人规定过一个service要对应一个dao的.dao是以一个数据库操作为基本单位，service是以完成一个业务逻辑为一个基本单位，这两者完全不该有什么数量上的对应关系。

用implementors试一试，我用的还是0.0.16版本，不知道新版本出来没有。

service与dao的关系是针对楼上的观点提出的，没有谁规定一个service一个dao，但是在楼上出现了很多这样的观点：一个service，一个dao。

82 楼 corelengine 2008-09-27  

单元功能不复杂servise写到一个文件里,方便在spring里配置,好维护.
找文件时间在要命

81 楼 1314520ln 2008-09-27  

大部分人还不了解接口是干嘛的啊..为什么要分那么多层.

80 楼 PlayGod1984 2008-09-26  

guoping007 写道

mingo 写道

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

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

我觉得说的在理，但是很多事情不能只看眼前，一定从长远来看这个项目以后的扩展性，如果会扩展，我想舍弃眼前的一些利益是必须的

79 楼 melode11 2008-09-26  

tibetjungle 写道

melode11 写道

godoo 写道

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

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

测试我写的不多，不过我想写测试要替换一个伪DAO的话，使用匿名内部类也能实现这个目的。

用接口最不方便的地方不是要多些这些接口文件，是本来如Eclipse这种IDE可以用Ctrl+点源码，从Service中写的DAO类名直接找到DAO类，用了接口，就必须得自己手工打开这些实现类。
要有修改，也必须得两个文件一起改，真是不胜其烦，感觉这种直接提取所有方法组成Interface的做法，是对Interface功用的扭曲。

Eclipse中早就有插件，可以直接跳转到接口的实现类。

接口定义好后需要不停地修改吗？如果需要，那是设计有问题，没有谁隔三叉五地去修改接口的参数。

另外，个人觉得还是没有必要一个service一个dao，dao是为service服务的，一个service可以调用多个dao，一个dao也可以为多个service服务，到底一个service要多少dao，这要看dao设计的粒度。

只有实现类跳到接口,哪有接口跳到实现类?
古板的web项目和很多产品类项目又不同，模块无数多，互相关系却不大，谁有空靠YY就能把需要的接口给写全了，都是按需增加的。
说就事论事嘛，总是要牵扯到设计上去，CRUD项目需要这么多设计么？

不必要一个service一个dao倒没错，哪有人规定过一个service要对应一个dao的.dao是以一个数据库操作为基本单位，service是以完成一个业务逻辑为一个基本单位，这两者完全不该有什么数量上的对应关系。

78 楼 抛出异常的爱 2008-09-26  

ltian 写道

right now 写道

csdn的毛爷爷，我想问一下，很多动态语言中没有接口的概念，请问怎么面向接口编程

此接口非彼接口。
面向对象中方法论中的面向接口编程并不是说语言要有专门的“接口”定义支持。面向接口编程里面的接口是广义的，
虚基类可以充当“接口”，甚至约定好的不做任何实现的暴露公开方法的基类都可以作为“接口”。

colbol的接口是一个字串的第几位到第几位,表示 用户名 从第几位到第几位 是 时间...

77 楼 netfork 2008-09-26  

强烈建议大家读一下《iBATIS in Action》，自然找到答案！

76 楼 china8jie 2008-09-26  

tibetjungle 写道

melode11 写道

godoo 写道

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

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

测试我写的不多，不过我想写测试要替换一个伪DAO的话，使用匿名内部类也能实现这个目的。

用接口最不方便的地方不是要多些这些接口文件，是本来如Eclipse这种IDE可以用Ctrl+点源码，从Service中写的DAO类名直接找到DAO类，用了接口，就必须得自己手工打开这些实现类。
要有修改，也必须得两个文件一起改，真是不胜其烦，感觉这种直接提取所有方法组成Interface的做法，是对Interface功用的扭曲。

Eclipse中早就有插件，可以直接跳转到接口的实现类。

接口定义好后需要不停地修改吗？如果需要，那是设计有问题，没有谁隔三叉五地去修改接口的参数。

另外，个人觉得还是没有必要一个service一个dao，dao是为service服务的，一个service可以调用多个dao，一个dao也可以为多个service服务，到底一个service要多少dao，这要看dao设计的粒度。

有些道理，
這個貼應該長久討論。