我在某些文章中读到，在hibernate状态下DAO不是强制性的，其实现是“取决于”的，换句话说，我们可以在ORM与DAO模式之间进行选择。
好的，假设我不想使用DAO模式，所以我只使用了由hibernate（my ORM）提供的会话CRUD和查询操作。
特别是对于“搜索”和“查找”查询而言，始终重写它们是不正确的，因此将它们放入一个类是合理的想法。
但是，此类是一个简单的DAO，而没有DAO模式和DAOFactory的所有实现，只是DAO的轻量级实现。因此，关键是我们始终需要DAO，而选择是重型DAO实现还是轻型DAO实现？
我说的错了吗？
编辑 我遇到的另一个问题是在哪里放置dao交互，例如我必须登录一个User并编写登录日志（我知道无用的示例…）
因此，在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吗？如果我想处理异常，最好的方法是在业务逻辑中？
EDIT2 让我们假设使用DAO模式，这样做的主要原因是能够在tecnhology（ORM-> JDBC等）之间进行切换，一切正常，但是在哪里可以处理hibernate会话和事务？我不能将其放入DAO中，这是一种安全模式，也无法将其放入服务层中，因为在hiphotetycal交换机中，我必须删除所有此事务（因为其他技术可能不会使用它们）。
ORM和DAO是正交的概念。一个问题与对象如何映射到数据库表有关，另一个问题是一种用于编写访问数据的对象的设计模式。您不要在它们之间选择。您可以使ORM和DAO是同一应用程序，就像您不需要ORM来使用DAO模式一样。
就是说，尽管您实际上 不需要 任何东西，但应该使用DAO。该模式适用于模块化代码。您将所有持久性逻辑都放在一个位置（关注点分离，消除泄漏的抽象）。您可以自己与应用程序的其余部分分开测试数据访问。而且，您可以测试与数据访问隔离的应用程序的其余部分（即，您可以模拟您的DAO）。
另外，即使实现数据访问可能很困难，遵循DAO模式也很容易。因此，它花费很少（或没有花费），您却收获很多。
编辑- 对于您的示例，您的登录方法应为某种AuthenticationService。您可以在那里（在登录方法中）处理异常。如果使用Spring，它将为您管理很多事情：（1）事务，（2）依赖项注入。您无需编写自己的事务或dao工厂，只需定义服务方法周围的事务边界，然后将DAO实现定义为bean，然后将其连接到服务中即可。
编辑2
使用此模式的主要原因是要分开关注点。这意味着所有持久性代码都放在一个地方。这样做的副作用是可测试性和可维护性，以及使以后更容易切换实现的事实。如果要构建基于Hibernate的DAO，则可以绝对在DAO中操纵会话，这是您应该做的。反模式是当与持久性相关的代码发生在持久层之外时（泄漏抽象定律）。
交易有点棘手。乍一看，事务似乎是持久性的问题，而且确实如此。但是它们不仅是持久性的问题。事务也是您服务的关注点，因为您的服务方法应该定义一个“工作单元”，这意味着服务方法中发生的所有事情都应该是原子的。如果您使用hibernate事务，那么您将不得不在DAO之外编写hibernate事务代码，以定义使用许多DAO方法的服务周围的事务边界。
但是请注意，事务可以独立于您的实现-无论是否使用hibernate，都需要事务。还要注意，您不需要使用hibernate事务处理机制，可以使用基于容器的事务，JTA事务等。
毫无疑问，如果您不使用Spring或类似工具，那么交易将很痛苦。我强烈建议使用Spring来管理您的事务，或者使用EJB规范，我 相信 您可以在其中使用注释定义服务周围的事务。
查看以下链接，了解基于容器的交易。
会话和交易
我从中得到的是，您可以轻松地在服务级别上在DAO之外定义事务，而无需编写任何事务代码。
另一个（不太优雅）的替代方法是将所有原子工作单元放在DAO中。您可能具有用于简单操作的CRUD DAO，然后具有执行多个CRUD操作的更复杂的DAO。这样，您的程序化事务将保留在DAO中，并且您的服务将调用更复杂的DAO，而不必担心事务。
请注意，接口的定义是如何实现的，因此您的业务逻辑仅关心UserDao的行为。它不在乎实现。您可以使用hibernate或仅使用JDBC编写DAO。因此，您可以更改数据访问实现，而不会影响程序的其余部分。
