如何在Hibernate / JPA中使用DAO？

Question

假設下面描述的DAO結構和組件交互，如何將DAO與持久層（例如休眠和頂部鏈接）一起使用？ 它們應該/不應該包含哪些方法？

將代碼直接從DAO移到服務中是否是不好的做法？

例如，假設對於每個模型，我們都有一個DAO（可能實現也可能不實現基本接口），其外觀類似於以下內容：

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

組件交互模式為-

服務> DAO>模型

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沒有進行孤兒處理，因此我們將其添加到了后端服務中。

甚至簡單的普通DAO都具有價值，僅僅是作為抽象點。

我們只是不需要像過去那樣為每組對象（CustomerDAO，OrderDAO等）制作一個。

Answer 2

恕我直言，DAO通常不應該包含任何方法。 它應確切包含您的應用程序需要的那些方法。 這可能因型號而異。

在Hibernate和JPA中，諸如save和retrieve類的方法是會話/實體管理器提供的“瑣碎”操作，因此，除了將服務/業務邏輯與實際隔離之外，我看不出將它們添加到DAO的意義。持久性實現。 但是，JPA本身已經是隔離。

將持久性代碼直接移入服務層會將兩者捆綁在一起。 在小型應用程序中，這也許可以，但是隨着時間的流逝，即使小型應用程序也趨於增長，維護成為一個問題。 將單獨的關注點分開可以幫助保持代碼干凈，從而更易於理解，擴展和重用。