Javadream

注：標題寫得有點夸張，這是本人的文學修養問題，不在討論范圍之內。這里的前提是使用貧血模型模式和輕量級JEE Web，沒有考慮分布式。

這些天在看Hibernate的資料，除了對它的強大感到驚人之外，更多的就是煩惱，因為太多本來確定的理論現在都變得相當站不住腳，而且有些東西百思不得其解。這得從DAO層開始講起，一般的架構是這樣的：
     Web層
      |
   Service層
      |
     DAO層
      |
    數據庫

因為DAO層主要負責對象持久的操作，而Service層則是除持久操作外操作，所以各自分工，層次分明。但是因為在按各種條件檢索數據的時候，Service層需要向Web層提供相應的接口，比如說接用戶名查訂單需要一個接口，按時間查訂單需要一個接口等等，但是這樣使得DAO層同時也必須提供同樣的接口，這樣，當有新的需求時就要添加兩個接口，而且通常Service層只是簡單的調用一下DAO層而已。

而另有一種方法就是Service類繼承DAO類，覆蓋相應的方法，這使得只修改Dao的方法就可以了。但是就有了問題，因為Service層的接口要求的參數和DAO層的參數會不一樣，這造成重載了相應的方法而不是覆蓋相應的方法，也就是說Service類無端多了很多接口，使得調用有些混亂。

從實際來看，常用后面那種方法，而且和上一層程序員搞好默契，哪些方法可以用，哪些不可以。但是這帶來的問題就是一不小心調用錯了就麻煩了。而前一種雖然修改麻煩一點，但至少使得Service層是干凈的接口，沒有不用得上的接口。

其實在日常的開發中總是這樣認為，DAO有沒有一個萬能的接口可以用于檢索對象？就旭上面所說的，按用戶名查訂單等這樣的操作，有沒有一個通用的接口去實現呢？DAO不是做不到，而是開發這樣的功能相當復雜，而且難以重用，似乎這是一個理想，一個難以實現的理想了。

從上面的討論中我們可以看得到，DAO就是持久層，他負責對象的CRUD，而且我們希望有一個通用的檢索對象的接口。

終于，我們的Hibernate橫空出世了（超級賽亞人？）。他的Session實現了對象的CRUD，與此同時接供了基于HQL的Query接口，用于按條件檢索對象，從這個意義上來說，他就是一個DAO實現，我們可以直接在Service層使用Hibernate做為的DAO。

可是為什么還有這么多人要在Hibernate之上建立DAO呢？無非就是做一個可更換持久層的系統（如JDO），又或者把Hibernate的一些Session操作隱藏起來，使得Service層的代碼更為簡潔明了。對于后面的說法還可以說得過去，可是前面的講法就不妥了，因為通用的檢索接口各個ORM實現都不相同，那么DAO很難做得到通用，這就又回到前面沒有Hibernate之前的困境了；而與此同時，使用DAO也會有一些問題，就是必定是跨了多個Session進行的操作，那么在Update操作時就會把整個對象（這個對象是游離態的）進行所有字段的進行更新，實際上只有一兩個字段被修改了，對于一些計數操作，這樣的方式的性能相當差勁（比如說一篇文章有多少人閱讀過了這樣的計數）。

其實會這么樣，我會直接在Service使用Hibernate做為DAO，在大多數中小型應用中，很少（幾乎沒有）有人會要求更換持久層中間件的，所以根本不用擔心，而且維護也并沒有想象中復雜，因為始終還是得對新的DAO層進行了解的，不是嗎？