如何使用hibernate/jpa使用DAO？

假设DAO结构和组件交互如下所述，应如何将DAO与持久层（如hibernate和toplink）一起使用？他们应该/不应该包含哪些方法？如何使用hibernate/jpa使用DAO？

将代码从DAO直接移动到服务是否是不好的做法？

例如，让我们说，每一个模型中，我们有一个DAO（可能会或可能不会实现基本接口），看起来像下面这样：

public class BasicDao<T> { 
public List<T> list() { ... } 
public <T> retrieve() { ... } 
public void save() { ... } 
public void delete() { ... } 
}

组件交互模式 -

服务> DAO>模型

2010-04-16 Ari

我们发现（和其他人一样），在JPA调用之上编写一个通用DAO作为一个薄垫片很简单。

许多人只是在JPA之上。例如，早期我们只需要：

public <T> T update(T object) { 
    return em.merge(object); 
}

但是具有图层的好处是您的图层可扩展，而EM不是。

后来我们增加了一个过载：

public Thing update(Thing object) { 
    // do magic thing processing 
}

所以，我们的层基本上是完整的，但可以处理加工定做。

例如，后来，由于早期的JPA没有孤儿处理，我们在后端服务中添加了这个功能。

即使是简单的常见DAO也具有价值，仅仅作为一个抽象点。

我们只是不需要为每一组对象（CustomerDAO，OrderDAO等）创建一个类似于过去的日子。

2010-04-16 22:06:59

IMHO没有方法在DAO “应该” 包含一般。它应该包含你的应用程序需要的那些方法。这可能因型号而异。

在Hibernate和JPA，像save和retrieve方法是由会话/实体管理器提供的“微不足道”的操作，所以不从，也许绝缘服务/商务看到它们添加到DAO多一点，除了来自实际持久性实现的逻辑。但是，JPA本身已经是一个绝缘体。

将持久代码直接移入服务层会将两者捆绑在一起。在一个小应用程序中，这可能是好的，但随着时间的推移，即使小应用程序往往会增长，维护成为一个问题。保持分开的关注点有助于保持代码清洁，从而更容易理解，扩展和重用。

2010-04-16 22:05:04

回答