java - DAO vs ORM( hibernate )模式

Question

关闭。这个问题是opinion-based .它目前不接受答案。












想改善这个问题吗？更新问题，以便可以通过 editing this post 用事实和引文回答问题.

7年前关闭。




Improve this question




我在一些文章中读到 DAO 对于 Hibernate 不是强制性的，它的实现是“取决于”，换句话说，我们可以在 ORM 与 DAO 模式之间进行选择。

好的，让我们假设我不想使用 DAO 模式，所以我只使用了 hibernate(我的 ORM)提供的 session CRUD 和查询操作。

特别是对于“搜索”和“查找”查询，总是重写它们是不正确的，因此将它们放在一个类中是合理的。

但是这个类是一个简单的 DAO，没有 DAO 模式和 DAOFactory 的所有实现，只是一个 DAO 的轻量级实现。
所以，关键是我们总是需要一个 DAO 并且选择是重 DAO 实现还是轻量级 DAO 实现？

我说的有错吗？

编辑
我遇到的另一个问题是在哪里放置 dao 交互，例如我必须登录一个用户并编写登录日志(我知道无用的例子......)

所以在 DAO 模式中，我有所有通用的 dao 实现，一个 DAOFactory，最后是 UserHibernateDAO 和 LogHibernateDAO。
登录操作是经营方法 :

private void login(String username, String password){
    daoFactory.beginTransaction();
    UserDAO userDao=daoFactory.HIBERNATE.getUserDao();
    LogDAO logDao=daoFactory.HIBERNATE.getLogDao();
    if(userDao.checkAccount(username, password){
        User user=userDao.findByAccount(username, password);
        logDao.save(new Log("log-in", user);
    }
    daoFactory.commit();
}

这合理吗？我可以这样使用 dao 吗？
如果我想处理异常，最好的地方是在业务逻辑中？

编辑2
让我们假设使用 DAO 模式，这样做的主要原因是能够在技术(ORM->JDBC 等)之间切换，一切都很好，但是我在哪里可以处理 hibernate session 和事务？
我不能把它放到一个 DAO 中，它是反模式，我不能把它放到服务层，因为在一个 hipohtetycal 交换机中我必须删除所有这些事务(因为其他技术可能不会使用它们)。

Answer 1

ORM 和 DAO 是正交的概念。一个与对象如何映射到数据库表有关，另一个是用于编写访问数据的对象的设计模式。你不会在它们之间做出选择。你可以让 ORM 和 DAO 是同一个应用程序，就像你不需要 ORM 来使用 DAO 模式一样。

也就是说，虽然你从来不需要任何东西，但你应该使用 DAO。该模式适用于模块化代码。您将所有持久性逻辑都放在一个地方(关注点分离，与泄漏抽象作斗争)。您允许自己与应用程序的其余部分分开测试数据访问。并且您允许自己测试与数据访问隔离的应用程序的其余部分(即您可以模拟您的 DAO)。

另外，遵循 DAO 模式很容易，即使实现数据访问可能很困难。所以它花费你很少(或没有)，而你获得了很多。

编辑--
关于您的示例，您的登录方法应该在某种 AuthenticationService 中。您可以在那里处理异常(在 login 方法中)。如果您使用 Spring，它可以为您管理很多事情:(1) 事务，(2) 依赖注入(inject)。您不需要编写自己的事务或 dao 工厂，您只需围绕服务方法定义事务边界，并将 DAO 实现定义为 bean，然后将它们连接到您的服务中。

编辑2

使用该模式的主要原因是分离关注点。这意味着您所有的持久性代码都在一个地方。这样做的副作用是可测试性和可维护性，并且这使得以后更容易切换实现。如果您正在构建基于 Hibernate 的 DAO，您绝对可以在 DAO 中操作 session ，这就是您应该做的。反模式是当与持久性相关的代码发生在持久层之外时(泄漏抽象定律)。

交易有点棘手。乍一看，事务似乎是一个持久性问题，而且确实如此。但它们不仅仅是对持久性的关注。事务也是您的服务关注的问题，因为您的服务方法应该定义一个“工作单元”，这意味着在服务方法中发生的一切都应该是原子的。如果您使用 hibernate 事务，那么您将不得不在 DAO 之外编写 hibernate 事务代码，以围绕使用许多 DAO 方法的服务定义事务边界。

但请注意，事务可以独立于您的实现——无论您是否使用 hibernate ，您都需要事务。另请注意，您不需要使用 hibernate 事务机制——您可以使用基于容器的事务、JTA 事务等。

毫无疑问，如果您不使用 Spring 或类似的东西，事务将会很痛苦。我强烈建议使用 Spring 来管理您的事务，或者使用 EJB 规范，我相信您可以使用注释围绕您的服务定义事务。

查看以下链接，了解基于容器的交易。

Container-Managed Transactions

Sessions And Transactions

我从中收集到的是，您可以轻松地在服务级别定义 DAO 之外的事务，并且您不需要编写任何事务代码。

另一种(不太优雅的)替代方案是将所有原子工作单元放在 DAO 中。您可以拥有用于简单操作的 CRUD DAO，然后是执行多个 CRUD 操作的更复杂的 DAO。这样，您的程序化事务就留在 DAO 中，您的服务将调用更复杂的 DAO，而不必担心事务。

以下链接很好地说明了 DAO 模式如何帮助您简化代码

AO vs ORM(hibernate) pattern

(谢谢@ daff)

请注意接口(interface)的定义如何使您的业务逻辑只关心 UserDao 的行为。它不关心实现。您可以使用 hibernate 或仅使用 JDBC 编写 DAO。因此，您可以更改数据访问实现，而不会影响程序的其余部分。