java 包 dao 和 dao.impl 问题

kaipizhe
  • 1.3k

我看 MVC 设计中 dao 层和 service 都说要加一个 dao.impl 而我在实际应用中感觉加一个 dao.impl 非常麻烦,比如我需要修改 dao.impl 还要修改 dao 这样不增加了负担吗?他的好处是干什么用的,一直没明白。

回复
阅读 23.9k
11 个回答

dao中存在是接口(interface)
dao.impl中存在的是接口的具体实现(class)

至于好处,去查查接口的定义。

更新。。。。

举个例子

dao中有

public interface UserDAO {
    public List getUser();
}

dao.imple中

public class JdbcUserDao implements UserDAO{
        @Override
    public List getUser() {
        //do sth.
        return null;
    }
}

在往后的某一天,需要用hibernate来操作数据库的时候。
只要写一个 HibernateUserDao来实现UserDAO就行了。

接口定义的是规范。并不关心具体实现。
我的github上有一份自己对java各种关键字做的总结,其中关于接口在设计方面的描述是:

接口作为系统与外界交互的窗口,接口体现是一种规范。对于接口的实现者而言,接口规定了实现者必须向外提供哪些服务(以方法的形式来提供);对于接口调用者
而言,接口规定了调用者可以调用哪些服务,以及如何调用这些服务(就是如何来调用方法的)。当一个程序中使用接口时,接口是多个模块之间的耦合标准;当多
个应用程序之间使用时,接口时多个程序之间的通信标准。
从某种程度来说,接口类型整个系统中的“总纲”,它制定了系统之间各个模块应该遵循的标准,因此一个系统中的接口不应该经常改变。一旦接口改变,对整个系统
甚至其他系统的影响将是辐射式的,导致系统中大部分类需要重写。

@zaz @reeco @finallygo 说的都是面向接口编程的优势,这些内容不需要怀疑。
但根据个人的经验,感觉这是一个可以酌情妥协的设计方案。笔者一直做的都是一些小项目,有时候也用到过一些设计模式,但是题主说的这种设计,感觉对小项目来说,弊大于利,代码层数太多,多了许多没有用处的接口代码,而且,接口在编程中是起不到应有的作用,就比如@zaz 所说,一个UserDao的接口可以有数个不同的实现,但是,项目小的情况下,这种情况用的还是比较少的。并且,题主既然能问出这种问题,那么我想,在题主的项目中用到dao层接口的地方应该也是很少的。

面向接口编程是一种设计思想,个人感觉,所有的设计思想都应该是活的,不应该生硬的直接搬过来用。开发者首先应该理解这种思想,然后再看程序是否需要用到这种设计,没有必要的话,即使是再优秀的设计,对程序来说,也是没有多大意义的。

List<Integer> list = new ArrayList<Integer>();
List<Integer> list = new LinkedList<Integer>();
........

java API 中存在大量这样的设计,至于为什么,建议楼主看看设计模式中的面向接口编程。好处说起来很空洞,只有上手了1,2个项目才能有所体会的。有些经验与心得必须得经历过才能得到。

一个是抽象,一个是具体
接口正常来说应该是一开始就设计好的,不能随意的修改,如果你经常修改,首先需要考虑dao层是否考虑的足够充分
而为什么有接口层,是为了进行更好的隔离,最简单的例子就是,如果你对service层需要进行单元测试了,而又不希望你对dao层进行实际的操作(可能是条件不允许),这时你很可能需要针对测试去mock一个dao出来,接口的优势就体现出来了

分dao和service层是程序解耦需要,这么做可以降低程序耦合度,可以在更换不同dao和不同service时,可以做到最低最小的修改程序代码。另外dao和impl的关系就是想规范和实现的关系,规范改了,实现当要改然,反之不一定。为了程序的解耦,这么做还是可接受的。不然像spring这种框架会这么火。

其实就是解耦,比如你的你有一个dao,dao.impl是一个MYSQL的实现,后来有需求要求改为Oracle实现,你只需要修改dao.impl为Oracle实现就好了,不需要修改dao和使用到dao的地方

ltlovezh
  • 1
新手上路,请多包涵

上面说的很好了,以我自己的体会,在小项目中,真是弊大于利。项目比较复杂,多人合作,需求变动性比较大的话,还是很有用的的,主要还是接口的隔离性,可以解耦模块之间的关联。

dao和daoiml体现了两个思想。
一是分层。我们为什么要分层,分层解决了我们什么问题?分层又有什么优缺点?具体见我的博客:http://www.inter12.org/archives/396
二是OO设计原则中的依赖倒置,抽象隔离。再具体点就是两点:
1.高层模块不应该依赖于底层模块,两者应该都依赖于抽象
2.抽象不应该依赖于细节,细节应该依赖于抽象
好处就是高内聚,低耦合,这两个用烂的词!!

如果没有更换数据库的需求,其实去掉也没事的

这仅仅是使用了接口而已,建议你先了解使用接口的好处

撰写回答
你尚未登录,登录后可以
  • 和开发者交流问题的细节
  • 关注并接收问题和回答的更新提醒
  • 参与内容的编辑和改进,让解决方法与时俱进
宣传栏