Question

假设下面描述的DAO结构和组件交互，DAO应该如何与hibernate和toplink等持久层一起使用？它们应该/不应该包含哪些方法？

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

例如，假设对于每个模型，我们都有一个DAO（可能会或可能不会实现基本接口），如下所示：

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

组件交互模式是 -

服务＆gt; DAO＆gt;模型

Answer 1

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

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

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

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

后来我们添加了一个重载：

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

因此，我们的图层基本上完好无损，但可以处理自定义处理。

例如，稍后，由于早期的JPA没有Orphan处理，我们在后端服务中添加了。

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

我们不需要像过去那样为每组对象（CustomerDAO，OrderDAO等）制作一个。

Answer 2

恕我直言，DAO“应该”包含的方法一般没有。它应该包含您的应用程序所需的那些方法。这可能因型号而异。

在Hibernate和JPA中，像save和retrieve这样的方法是会话/实体管理器提供的“平凡”操作，所以我没有看到将它们添加到DAO中的重点，分开从可能使服务/业务逻辑与实际持久性实现隔离开来。但是，JPA本身已经是一种绝缘材料。

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