Hibernate支持DetachedCriteria這是一個非常有意義的特性！我們知道在常規的Web編程中有大量的動態條件查詢即用戶在網頁上面自由選擇某些條件程序根據用戶的選擇條件動態生成SQL語句進行查詢
針對這種需求對於分層應用程序來說Web層需要傳遞一個查詢的條件列表給業務層對象業務層對象獲得這個條件列表之後然後依次取出條件構造查詢語句這裡的一個難點是條件列表用什麼來構造？傳統上使用Map但是這種方式缺陷很大Map可以傳遞的信息非常有限只能傳遞name和value無法傳遞究竟要做怎樣的條件運算究竟是大於小於like還是其它的什麼業務層對象必須確切掌握每條entry的隱含條件因此一旦隱含條件改變業務層對象的查詢構造算法必須相應修改但是這種查詢條件的改變是隱式約定的而不是程序代碼約束的因此非常容易出錯
DetachedCriteria可以解決這個問題即在web層程序員使用DetachedCriteria來構造查詢條件然後將這個DetachedCriteria作為方法調用參數傳遞給業務層對象而業務層對象獲得DetachedCriteria之後可以在session范圍內直接構造Criteria進行查詢就此查詢語句的構造完全被搬離到web層實現而業務層則只負責完成持久化和查詢的封裝即可與查詢條件構造完全解耦非常完美！這恐怕也是以前很多企圖在web層代碼中構造HQL語句的人想實現的夢想吧！
示例代碼片段如下
web層程序構造查詢條件
java代碼
DetachedCriteria detachedCriteria = DetachedCriteria
forClass(Department
class);
detachedCriteria
add(Restrictions
eq(
name
department
))
createAlias(
employees
e
)
add(Restrictions
gt((
e
age
)
new Integer(
)));
Department和Employee是一對多關聯查詢條件為
名稱是department開發部門部門裡面的雇員年齡大於歲
業務層對象使用該條件執行查詢
java代碼
detachedCriteria
getExecutableCriteria(session)
list();
最大的意義在於業務層代碼是固定不變的所有查詢條件的構造都在web層完成業務層只負責在session內執行之這樣代碼就可放之四海而皆准都無須修改了
然而Spring和Hibernate的DetachedCriteria有不兼容的問題因此在Spring環境下面使用Hibernate需要注意
Spring的HibernateTemplate提供了Hibernate的完美封裝即通過匿名類實現回調來保證Session的自動資源管理和事務的管理其中核心方法是
java代碼
HibernateTemplate
execute(new HibernateCallback() {
public Object doInHibernate(Session session) throws HibernateException {
}
}
[] [] []
From:http://tw.wingwit.com/Article/program/Java/ky/201311/29142.html
