DAO vs ORM（hibernate）模式 [英] DAO vs ORM(hibernate) pattern
问题描述
我读了一些文章，DAO并不是强制性的hibernate，它的实现是依赖，换句话说，我们可以选择ORM和DAO模式。
好的，我们假设我不想使用DAO模式，所以我只使用hibernate（我的ORM）提供的会话CRUD和查询操作。
特别对于搜索和查找查询是不正确的重写它们总是，所以合理的想法把它们放入一个类。
但是这个类是简单的DAO没有所有的DAO模式和DAOFactory的实现，只是一个轻量级的DAO实现。
那么关键是我们需要一个DAO，而且选择是重的DAO实现vs轻量级DAO实现？
我说的是错的？ p>
编辑
另一个问题是我将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吗？
如果我想要处理异常，那么做一个更好的工作是一个业务逻辑？
strong> EDIT2
我们假设使用DAO模式，主要的原因是能够在tecnhology（ORM-> JDBC etc ..）之间切换，这一切都很好，但是我可以在哪里处理hibernate会话和事务？
我不能把它放到一个DAO，它是anty模式，我不能把它放在一个服务层，因为在一个hipohtetycal交换机，我必须删除所有这一切交易（因为其他技术可能不会使用它们）。
ORM和DAO是正交概念，一个与对象如何被映射到数据库表，o这是用于编写访问数据的对象的设计模式。你不要选择之间。你可以让ORM和DAO是同一个应用程序，就像你不需要ORM来使用DAO模式一样。
需要任何东西，你应该使用DAO。该模式适用于模块化代码。您将所有持久性逻辑保持在一个位置（分离关注点，打击漏洞抽象）。您允许自己与应用程序的其余部分分开测试数据访问。并且您允许自己测试与数据访问隔离的应用程序的其余部分（即，您可以模拟您的DAO）。
另外，遵循DAO模式很容易，即使实现数据访问也很困难。所以它花费你很少（或没有），你会获得很多。
编辑 -
关于你的例子，您的登录方法应该是某种AuthenticationService。您可以处理这里的异常（在登录方法中）。如果你使用Spring，它可以为你管理一堆东西：（1）事务，（2）依赖注入。您不需要编写自己的交易或工厂，您可以在服务方法周围定义交易边界，并将DAO实现定义为bean，然后将其连接到您的服务中。
EDIT2
使用该模式的主要原因是分离问题。这意味着所有的持久性代码都在一个地方。这样做的一个副作用是可测试性和可维护性，以及这样可以使以后更容易切换的事实。如果您正在构建基于Hibernate的DAO，则可以绝对地操作DAO中的会话，这是您应该做的。反模式是持久性相关代码发生在持久层之外（泄漏抽象规律）时。
交易有点棘手。乍一看，交易可能似乎是持久性的关注，而且它们是。但它们不仅仅是持久的关注。事务也是您的服务的关注，因为您的服务方法应该定义工作单位，这意味着，在服务方法中发生的一切都应该是原子的。如果您使用hibernate事务，那么您将不得不在DAO之外编写hibernate事务代码，以便在使用许多DAO方法的服务上定义事务边界。
但请注意，事务可以独立于您的实现 - 无论您是否使用hibernate，都需要事务。还要注意，您不需要使用hibernate事务机制 - 您可以使用基于容器的事务，JTA事务等。
毫无疑问，如果你不使用Spring或类似的东西，交易将是一种痛苦。我强烈建议使用Spring管理您的交易，或者EJB规范，我相信可以使用注释来定义您的服务周围的交易。
检查列出以下链接，用于基于容器的事务。
我从这里收集的是，您可以轻松地在服务级别定义DAO之外的交易，而不需要编写任何交易代码。
另一种（不太优雅）的替代方法是将所有原子单元的工作放在DAO中。您可以使用CRUD DAO进行简单的操作，然后再执行多个CRUD操作的更复杂的DAO。这样，您的程序化交易将保留在DAO中，您的服务将调用更复杂的DAO，而不用担心交易。
以下链接是一个很好的例子，说明DAO模式如何帮助您简化代码
（thanx @ daff ）
请注意，interace的定义如何使您的业务逻辑只关心userDAO的。它不关心实现。你可以使用hibernate或者只是jdbc编写一个DAO。因此，您可以更改数据访问实现，而不会影响您的程序的其余部分。
i read in some articles DAO is not mandatory with hibernate and its implementation is by "it depends", in other words, we can choose between ORM vs DAO pattern.
Ok, let's assume that i don't want use a DAO pattern, so im using only session CRUD and query operation provided by hibernate(my ORM).
Especially for the "search" and "find" queries is not correct to rewrite them always, so is reasonable think to put them into a class.
But then this class is a simple DAO without all implementation of DAO pattern and DAOFactory, only a lightweight implementation of a DAO. So, the point is that we need alway a DAO and the choice is heavy DAO implementation vs lightweight DAO implementation?
What i said is wrong?
EDIT Another problem i have is where put dao interactions, for example i have to login an User and write a Log of the login (useless example i know...)
So in a DAO pattern i have all generic dao implementations, a DAOFactory and finally UserHibernateDAO and LogHibernateDAO. The login operation is a business method:
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();
}
Is this reasonable? Can i use dao in this way? If i want handle exception, the better place to do it is ina a business logic?
EDIT2 Let's assume to use a DAO pattern, the main reason to do it is to be able to switch between tecnhology(ORM->JDBC etc..), it all fine and ok, BUT where can i handle hibernate session and transaction? I can't put it into a DAO, it's anty pattern, and i can't put it into a service layer, becouse in a hipohtetycal switch i have to remove all this transaction(becouse other tecnhology may not use them).
ORM and DAO are orthogonal concepts. One has to do with how objects are mapped to database tables, the other is a design pattern for writing objects that access data. You don't choose 'between' them. You can have ORM and DAO is the same application, just as you don't need ORM to use the DAO pattern.
That said, while you never really need anything, you should use DAOs. The pattern lends itself to modularized code. You keep all your persistence logic in one place (separation of concerns, fight leaky abstractions). You allow yourself to test data access separately from the rest of the application. And you allow yourself to test the rest of the application isolated from data access (i.e. you can mock your DAOs).
Plus, following the DAO pattern is easy, even if implementing data access can be difficult. So it costs you very little (or nothing) and you gain a lot.
EDIT -- With respect to your example, your login method should be in some sort of AuthenticationService. You can handle exceptions there (in the login method). If you used Spring, it could manage a bunch of things for you: (1) transactions, (2) dependency injection. You would not need to write your own transactions or dao factories, you could just define transaction boundaries around your service methods, and define your DAO implementations as beans and then wire them into your service.
EDIT2
The main reason to use the pattern is to separate concerns. That means that all your persistence code is in one place. A side effect of this is, testability and maintainability, and the fact that this makes it easier to switch implementations later. If you are building Hibernate based DAOs, you can absolutely manipulate the session in the DAO, that is what you are supposed to do. The anti pattern is when persistence related code happens outside of the persistence layer (law of leaky abstractions).
Transactions are a bit trickier. At first glance, transactions might seem to be a concern of persistence, and they are. But they are not only a concern of persistence. Transactions are also a concern of your services, in that your service methods should define a 'unit of work', which means, everything that happens in a service method should be atomic. If you use hibernate transactions, then you are going to have to write hibernate transaction code outside of your DAOs, to define transaction boundaries around services that use many DAO methods.
But note that the transactions can be independent of your implementation -- you need transactions whether or not you use hibernate. Also note that you don't need to use the hibernate transaction machinery -- you can use container based transactions, JTA transactions, etc.
No doubt that if you don't use Spring or something similar, transactions are going to be a pain. I highly recommend using Spring to manage your transactions, or the EJB spec where I believe you can define transactions around your services with annotations.
Check out the following links, for container based transactions.
Container-Managed Transactions
What I am gathering from this is that you can easily define the transactions outside the DAOs at the service level, and you don't need to write any transaction code.
Another (less elegant) alternative is to put all atomic units of work within DAOs. You could have CRUD DAOs for the simple operations, and then more complicated DAOs that do more than one CRUD operations. This way, your programmatic transactions stay in the DAO, and your services would call the more complicated DAOs, and wouldn't have to worry about the transactions.
The following link is a good example of how the DAO pattern can help you simplify code
(thanx @daff)
Notice how the definition of the interace makes it so that you business logic only cares about the behavior of the UserDao. It doesn't care about the implementation. You could write a DAO using hibernate, or just jdbc. So you can change your data access implementation without affecting the rest of your program.
这篇关于DAO vs ORM（hibernate）模式的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
