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

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

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

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

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

     4）程序调试不方便。

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

 

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

评论

55 楼 mornstar 2008-09-24  

以上看得我崩溃了。（Eclipse快捷键推荐每个人都应该用熟，效率很高很多。）

应该说，项目中用Service的接口，多数是为了IOC；而DAO接口是为了冒名顶替进行Unit测试。

我只开发过很少的项目，都不大，而且都是LZ提倡的那种合并模式。数据通用简单的CRUD的写在一个CommonDAO当中。（第一只能查全表，第二完全不考虑事务）

但个人觉得这样子的话，Service层里面会充满一群群的引号括起来的HQL语句，还要处理try，看起来及其恶心，业务逻辑的思路都被各种HQL隔着。当维护的时候太虐待自己眼睛啥是干啥都不知道了。

所以觉得还是有必要用每个PO自己的DAO来处理CRUD，包括特殊查询和批量的CUD。
如此，Service中就是直接用DAO来处理:

dao.查询();
dao.取值();
if (取出来的值怎么怎么样了) {
  dao.批量修改();
}

这样多清楚，然后在这一层里面处理声明性事务。

54 楼 raymond.chen 2008-09-24  

shevliu 写道

您为什么不尝试下 ctrl+T呢？

太感谢啦，这样调试起来就快多了！

53 楼 shevliu 2008-09-24  

melode11 写道

godoo 写道

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

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

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

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

您为什么不尝试下 ctrl+T呢？

52 楼 bhdxyjg 2008-09-24  

我认为面向接口的编程方式还是比较好的，如果不采用接口的话可能会引起不必要的麻烦

51 楼 chenjianjx 2008-09-24  

这种大义凛然的教条腔很没必要
估计Rod Johnson提出 without EJB时，也会被你训个半死

lcllcl987 写道

有点晕.
此问题最终沦落到讨论interface是否有存在的必要了.
严重怀疑javaeye帖子的水准, 居然成了首页推荐.
OOP思想的重要核心之一就是面向interface编程.
否则, 你直接面向过程写程序得了.
省却java, qbasic更适合.

50 楼 melode11 2008-09-24  

lcllcl987 写道

有点晕.
此问题最终沦落到讨论interface是否有存在的必要了.
严重怀疑javaeye帖子的水准, 居然成了首页推荐.
OOP思想的重要核心之一就是面向interface编程.
否则, 你直接面向过程写程序得了.
省却java, qbasic更适合.

接口是很有用，但要看用在哪里，怎么用。

49 楼 fhjxp 2008-09-24  

我跟楼主的想法几乎完全一样，而且世界开发的三个项目中就是这样做的

48 楼 lcllcl987 2008-09-24  

有点晕.
此问题最终沦落到讨论interface是否有存在的必要了.
严重怀疑javaeye帖子的水准, 居然成了首页推荐.
OOP思想的重要核心之一就是面向interface编程.
否则, 你直接面向过程写程序得了.
省却java, qbasic更适合.

47 楼 shenrd666888 2008-09-24  

adolf506 写道

raymond2006k 写道

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

那是你的项目太小了吧！还没有经历真正的项目开发。分层是很有必要的，尤其是业务层和DAO。

个人觉得interface没有存在的必要，原因有三：
1：通常情况下，一个实现类一一对应一个接口，反而增加了代码量。
2：查找的时候还要去看是哪个具体实现类实现了该接口。
3：申明式事物，可以用cglib面向类动态代理。

46 楼 adolf506 2008-09-24  

raymond2006k 写道

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

那是你的项目太小了吧！还没有经历真正的项目开发。分层是很有必要的，尤其是业务层和DAO。

45 楼 yuanyao 2008-09-24  

SSailYang 写道

分层无定式。

对于接口，一般还是有的好。接口可以是方法定义更为清晰。而且在一些技术框架中，接口的使用是必须的。比如AOP、Mock，EJB 等等。当然如果这些你都用不到，项目也不大，不用接口没问题。但问题是小项目要用java做？python、php、ruby岂不更快更灵活

同意楼上的说法
   项目进行时～

44 楼 SSailYang 2008-09-24  

分层无定式。

对于接口，一般还是有的好。接口可以是方法定义更为清晰。而且在一些技术框架中，接口的使用是必须的。比如AOP、Mock，EJB 等等。当然如果这些你都用不到，项目也不大，不用接口没问题。但问题是小项目要用java做？python、php、ruby岂不更快更灵活

43 楼 melode11 2008-09-23  

godoo 写道

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

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

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

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

42 楼 gembler 2008-09-23  

我们目前项目结构：

view：没啥好说，有好的美工你想啥都行。
controller：数据验证，跳转逻辑，赋值/取值，等等
service：重点，包含各种各样的业务逻辑。
dao：纯粹做与存取数据有关的。

适当分层是需要的，还需要适当分模块，以便于把压力分发到其他服务器。

可是一对一的接口+实现，有点抗拒。
应该按业务来定义接口吧，而不是麻木地乱套。

41 楼 rocwon 2008-09-23  

mycybyb 写道

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

 

40 楼 yantao3000 2008-09-23  

这个是根据项目的不同而不同的

39 楼 melode11 2008-09-23  

chen-516888 写道

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

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

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

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

有过测试，CGLIB效率其实比java动态代理更高，因为CGLIB是bytecode生成技术，而动态代理是纯反射。
但对于spring来讲这些都不怎么重要，DAO本来就是单例，而且反射浪费的那一点点时间相对别的操作可以忽略，正如你已经跑了5000米了，还在乎多跑一米吗。

38 楼 miaomiao0307 2008-09-23  

我觉得接口还是必要的，而且分层也是必要的，接口易于扩展，

service是和业务有关，dao是和数据处理有关

37 楼 gosin 2008-09-23  

没有什么最合理,,根据领域 业务不同,,划分不同的层.

36 楼 csevan 2008-09-23  

有这种标准。。。  可以工厂化吧！~~