Javadream

注：標(biāo)題寫得有點夸張，這是本人的文學(xué)修養(yǎng)問題，不在討論范圍之內(nèi)。這里的前提是使用貧血模型模式和輕量級JEE Web，沒有考慮分布式。

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

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

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

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

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

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

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

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

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