如何使用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

回答