DAO到底是怎样一种设计模式？EJB是DAO设计模式的一种实现吗？

Question

好帖！
DAO 我感觉是实现了对持久层的操作，就是实现对数据库的所有操作，最好与表映射的对象分别建立DAO类！
至于EJB就是一个分布式的javaBean，并通过规范进行了划分！个人体会，听说新的ejb好像是3.0已经采用了hibernate，该看看新东西了！

Answer 1

楼主的理解很好。：）早期我们自己设计的DAO只能做到数据的存取和具体SQL无关，而使用Hibernate或EntityBean之后就能做到数据的存取跟具体数据库都无关了。窃以为实际上DAO要达到的目的是使“数据操纵”和“数据库访问”无关，达到业务逻辑与数据库访问逻辑的剥离，哪怕所谓的数据库仅仅是一个xml文件甚至普通文本文件。设计DAO的API是一件很有意思的事情，楼主不妨一试。

Answer 2

ejb3.0已经采用了hibernate吗？太好啦！还好我学过Hibernate。本来就感觉它应该成为一个标准。

Answer 3

对于DAO这个东西我的感觉是hibernaet和EJB与之无关。DAO出现的意图本来就是封装数据库操作，使业务中不出现任何与数据库操作相关的代码。但是这要看你的写法。实际上，如果你在业务中直接引用某个数据库操作的DAO，譬如说是针对Oracle的，那你在业务用都用了OracleDAO，那如果你换数据库的时候怎么办呢？还不是一样要把OracleDAO改成MysqlDAO等等。所以这个时候你就可能用一个Facotry来进行引用，同时将OracleDAO抽取为一个接口，比如BaseDAO，然后
public OracleDAO implements BaseDAO
如果以后改数据库的时候，只要再同样public MysqlDAO implements BaseDAO，然后实现Mysql的实现方法就可以了。最后在Factory中把对OracleDAO的应用改成对MysqlDAO的应用就行了。而Hibernate和EJB显然站在了一个比DAO还要高的地位，尤其是hibernate，它把对数据库的sql操作变成了面向OO的java操作，这更加面向对象。至于EJB，它的缺点是所有的操作都要引入EJB相关的东西，这样的话，你的系统耦合非常大，如果以后不用EJB了，所有bean操作都要改，而hibernate你可以只写一个基础类，在这个类中实现POJO持久化操作就行了。如果以后不用hibernate，别的地方基本上都不用改。这也是hibernate和EJB一个很大的差别。至于EJB3.0嘛，呵呵，SUN吸收了Gavin，使他成为了3.0中的一员，但是否就是hibernate的模式还不清楚，但据说目标就是要达到这种低耦合的效果。

Answer 4

btw:楼主所说的更重，就是我上面说的这种高耦合模式。另外，使用hibernate后是否还用DAO模式一直争论不清，有用的有不用的，但是从软件设计角度来讲，DAO仍然是必要的，所以我仍然在用它。而你为了图省事，就大可不用了。

Answer 5

我是个新手，我也想说两句，错误的话请大家指正阿。我觉得DAO实际上就是一个与数据库操作打交道的接口，我写的程序中DAOImpl 用来具体实现其方法，另外还有一个Manager或者System的类用来实现逻辑。

Answer 6

大家说的不错,一直以来,都为有些模式的应用场景感到有些困惑.今天看到大家的评论,感觉好了一些.DAO 和factory模式,是我目前经常用的,如何设计一个好的应用,如何把功能独立,把修改封闭,增加系统的可维护性,可修改性,都是这些模式的最初的目的.以后看来要好好斟酌才行啊.

Answer 7

DAO属于j2ee的一种设计模式吧，一般都是由工厂模式去实现如果用hibernate，命令模式比工厂模式要更好一点

Answer 8

我是楼主，看了大家的讨论，很有收获啊！
mxlmwl(飞星)，DAO只是一种设计模式，是一种思想，并没有限定我们必须怎么去实现，如果一种实现不能使得项目和具体数据库系统无关，那么它应该是不满足DAO设计模式思想的，因而也不能称其为DAO模式的一种实现吧？
在孙卫琴的《精通Struts：基于MVC的Java Web设计与开发》一书的6.4.2数据访问对象（DAO）设计模式一节中，是这么描述DAO设计模式的，原文节选如下：
“……围绕对象－关系的映射和持久化数据的访问，在软件领域中发展起来了一种数据访问对象设计模式。
“DAO模式提供了访问关系型数据库系统所需的所有操作的接口，其中包括创建数据库、定义表、字段和索引，建立表间的关系，更新和查询数据库等。DAO模式将底层数据访问操作与高层业务逻辑分离开，对上层提供面向对象的数据访问接口。……
“……许多ORM框架都采用DAO设计模式来实现，为模型层提供了访问关系型数据库的API。……
“……ORM框架是一种持久化框架，DAO是用于实现持久化框架的一种设计模式。”
综上理解，首先，DAO应该不只是java特有的，所有面向对象的语言都可以使用；另外，根据mxlmwl(飞星)对Hibernate的描述，Hibernate就应该是DAO的一种实现了，我也一直是这么理解的，可mxlmwl(飞星)后面的话似乎又说明Hibernate不是DAO的一种实现，而是在ORM框架下的另一种模式的实现，有点困惑，从DAO的原理来说，Hibernate似乎都能满足其要求，还不能说是DAO模式的一种实现吗？EJB是分布式环境下用的，其耦合度也确实比Hibernate要高，不过只要在EJB层上再加上一层（例如现在常用的Facade层），还是可以做到不在高层业务逻辑中引入EJB相关东西的，只是确实比Hibernate复杂得多。
这么看来严格来说，EJB应该不能算是DAO模式的一种实现了？
我对DAO和Hibernate都不熟悉，有诸多疑问，还望指教，谢谢

Answer 9

我也是最近才用到dao的，我接触到的是dao只是一组对象用于存放从数据库中读出来的或者是要写入数据库的数据，没有任何其他的接口。具体的数据库增删改查的操作由ibates实现。

Answer 10

呵呵，我说的可能你有些糊涂了。
“……许多ORM框架都采用DAO设计模式来实现，为模型层提供了访问关系型数据库的API。……
就是这个样子，hibernate就是采用DAO模式的，所以才比DAO又高了一层。也算是你说的那个意思吧，确切的说，它是以ORM为核心，以DAO为具体实现方式的这么一个东东。"如果一种实现不能使得项目和具体数据库系统无关，那么它应该是不满足DAO设计模式思想的，因而也不能称其为DAO模式的一种实现吧？"
这句话我觉得不正确，DAO只是隐藏了数据库的具体实现细节，但是并不代表就一定要保证它一定要和具体数据库系统无关，说白了一点，就是应该用工厂模式+DAO来达到你说的那个功能，DAO中并不包含工厂模式，就是这个样子。其实这些东西都是一些理论性的东西，解释起来蛮抽象的，还是用实际项目或代码来说比较好些。

Answer 11

也就是说DAO模式并没有要求一定要让上层业务逻辑和具体数据库无关？如果要做到和数据库无关，就需要使用工厂模式之类的附加手段？那Hibernate就是不仅符合了DAO设计模式，而且还实现了数据库无关，所以你说Hibernate站在了更高的高度？
其实我的抽象思维能力还是不错的，呵呵，所以比较喜欢讨论理论上的东西，站在更一般化的高度考虑问题，实际项目总是有其特殊性的
那能不能讨论一下，为什么EJB不能算是DAO设计模式的一种实现呢？仅仅因为需要在上层引入EJB的相关东西吗？DAO模式并没有限定这一点吧？EJB到底能不能算是DAO模式的一种实现呢？

Answer 12

有关o/r mapping设计到的模式，在一本企业架构模式的书上讲的很清楚，讲的蛮有深度的，建议去看一下

Answer 13

忘了说了，这本书是Martin Fowler写的

Answer 14

DAO就是DAO,EJB就是EJB,DAO是一个设计模式（解决问题的一种经验方式）,而EJB是SUN公司的J2EE技术中的一个规范，不仅仅是数据存取这么简单。
  DAO它主要解决数据存储和业务逻辑层的分离这类问题，它本身思想是很简单的，大家都喜欢说多态，喜欢说面向接口，DAO就是一个鲜活的例子，至于具体数据库无关这些都是具体实现上面的东西。
  Hibernate,或者其他O/R mapping工具，它们会用到DAO模式，但是它们可不仅仅是DAO这么简单。
  EJB中得Entity Bean是用于数据持久操作的。毫无疑问，里面的确有DAO的思想，但是不能说EJB就是DAO的实现。
  说白了， 楼主可能有些糊涂了， DAO它只是一种解决问题的思路， 而不能说到什么数据持久框架都用DAO去考虑。那就有些太看得起DAO了。有些看到胡子就叫爸爸的感觉，^_^  开玩笑。

Answer 15

我是楼主，super_zzw(之支吾)所说深有道理，DAO不过是一种思想（我也是一直这么认为的），Hibernate和EJB，或者别的什么映射机制也许只是借鉴了其思想，往往所包含的远远不只是DAO，如果将它们称为DAO的一种实现，如果从狭义上说也是说得过去的，但从广义上来说，它们又不只是DAO的一种实现，应该说这类似于B继承自A，B是A又不只是A吧？