mvc - java 包 dao 和 dao.impl 问题

Question

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

Answer 1

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各种关键字做的总结，其中关于接口在设计方面的描述是：

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

Answer 2

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

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

Answer 3

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

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

Answer 4

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

Answer 5

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

Answer 6

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

Answer 7

简单的说，为了方便用Strategy模式替换实现

Answer 8

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

Answer 9

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

Answer 10

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