Javadream

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

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

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

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

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

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

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

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

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

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