ORM和DAO是正交的概念。 一个问题与对象如何映射到数据库表有关,另一个问题是一种用于编写访问数据的对象的设计模式。 您不要在它们之间选择。 您可以使ORM和DAO是同一应用程序,就像您不需要ORM来使用DAO模式一样。
就是说,尽管您实际上不需要任何东西,但应该使用DAO。 该模式适用于模块化代码。 您将所有持久性逻辑都放在一个位置(关注点分离,消除泄漏的抽象)。 您允许自己与应用程序的其余部分分开测试数据访问。 而且,您可以测试与数据访问隔离的应用程序其余部分(即可以模拟DAO)。
另外,即使实现数据访问可能很困难,遵循DAO模式也很容易。 因此,它花费很少(或没有花费),您却收获很多。
编辑-对于您的示例,您的登录方法应为某种AuthenticationService。 您可以在那里(在登录方法中)处理异常。 如果使用Spring,它将为您管理很多事情:(1)事务,(2)依赖项注入。 您不需要编写自己的事务或dao工厂,只需在服务方法周围定义事务边界,然后将DAO实现定义为bean,然后将其连接到服务中即可。
我回来了
使用该模式的主要原因是要分开关注点。 这意味着所有持久性代码都放在一个地方。 这样做的副作用是可测试性和可维护性,以及使以后更容易切换实现的事实。 如果要构建基于Hibernate的DAO,则可以绝对在DAO中操纵会话,这是您应该做的。 反模式是当与持久性相关的代码发生在持久性层之外时(泄漏抽象定律)。
交易有点棘手。 乍一看,事务似乎是持久性的问题,而且确实如此。 但是它们不仅是持久性的问题。 事务也是您服务的关注点,因为您的服务方法应该定义一个“工作单元”,这意味着服务方法中发生的所有事情都应该是原子的。 如果您使用休眠事务,则必须在DAO之外编写休眠事务代码,以定义使用许多DAO方法的服务周围的事务边界。
但是请注意,事务可以独立于您的实现-无论是否使用休眠,都需要事务。 还要注意,您不需要使用休眠事务处理机制,可以使用基于容器的事务,JTA事务等。
毫无疑问,如果您不使用Spring或类似工具,那么事务将很痛苦。 我强烈建议使用Spring来管理事务,或者使用EJB规范,我相信您可以在其中使用注释定义服务周围的事务。
查看以下链接,了解基于容器的交易。
容器管理的交易
会话和交易
我从中得到的是,您可以轻松地在服务级别上在DAO之外定义事务,而无需编写任何事务代码。
另一种(不太优雅)的替代方法是将所有原子工作单元放在DAO中。 您可以使用CRUD DAO进行简单的操作,然后使用更复杂的DAO进行多个CRUD操作。 这样,您的程序化事务将保留在DAO中,并且您的服务将调用更复杂的DAO,而不必担心事务。
以下链接是DAO模式如何帮助您简化代码的一个很好的例子
AO vs ORM(休眠)模式
(感谢@daff)
请注意,接口的定义是如何实现的,因此您的业务逻辑仅关心UserDao的行为。 它不在乎实现。 您可以使用休眠或仅使用JDBC编写DAO。 因此,您可以更改数据访问实现,而不会影响程序的其余部分。