在企業開發過程中最頭痛的就是DA層（Data Access）的開發了，關系數據庫這個冬冬最討人嫌了，我就因為討厭關系數據庫，大學有一段時間很討厭寫web程序。
這些問題主要都是因為以前都是直接用Sql和數據庫打交道，每次web項目一把以上的時間花在了DA層了。工作后接觸的第一種DA技術是Spring support的DAO編寫，這樣就可以減少了很多的代碼，而且我還寫了一個代碼生成器來自動生成代碼，這樣開發速度就上來了，但是就算是這樣我們還是很煩惱，因為單表的操作是簡單了，但是多表的操作也是很煩惱，我們是用java代碼建立了一個DBManger層專門用來組裝多表的，當然很多人都是用sql進行多表的拼裝，這樣運行效率高，但是我們當時是選擇了開發效率，所以多表都是在DBManager層用java代碼組裝的，沒有利用數據庫的特性，這樣增加了web服務器的負擔。而且在做查詢的時候特別苦惱，每次都是把整個List全部給load出來了，這樣更加耗費內存了。比如我們的訂單列表的功能現在還沒有多少個訂單的時候都慢得不行了，一個是因為我們每次都load所有的Order對象，二是把Order對象的子對象也全部都Load出來了，本來用戶只是想看其中幾個訂單而已，而且我們也沒有做緩存，總之我們原來項目里面的DA層真的是問題重重。
這兩天把Hibernate引入了我們現在新的項目中來了，開心啊，開心，給我們帶來了解決上述問題的曙光：
1、在開發效率上面，我們現在所有的工作就是建立數據表，根據數據表生成hbm.xml的表對應Java bean的映射，以及生成java代碼。而DAO只是需要一行代碼。多表的聯合也是定義在hbm.xml中的，整個過程看不到一行sql語句，開心。這樣我們體系結構里面的DBManager就沒有存在的必要了。而且DAO也只是需要做一個DAO，現在我們就只有Order的DAO了，所有的操作都在這里進行。
2、運行效率上，首先利用了延時加載，數據如果不用就不load出來，這樣我們的Web服務器就沒有那么大的負擔了，然后就是多表的操作自動生成多表聯合的Sql充分利用數據庫的特性，這樣也是減少web的負擔。
接著最重要的問題就是在做訂單列表的時候，這里真的要好好贊揚一下HQL，這個Hibernate的查詢語言，用完全面向對象的方式解決了我們所有的問題：
a、分頁問題：這里我們可以使用Query接口的來限制每次從第幾個開始最多獲取多少個數據，這樣就可以按頁獲取數據，而且可以利用sum來得到數據的總量，這樣分頁功能就可以很容易實現了。根據我的試驗，速度比原來快了一倍以上，而且原來根據數據量的增長還是線性下降的，而現在保持比較平穩的速度。
b、構造小對象的問題：這個問題來自于訂單列表的時候只是需要幾個簡單的字段，而不需要整個order，這個問題可以通過在HQL的select語句中利用new語句來構造一個小的order對象，這樣進一步節省了web服務器的內存：）
c、聯合表查詢：比如需要根據聯系人信息查order，而聯系人是order的一個子表，這個時候可以利用HQL很直觀的寫出這樣的查詢:eg：select new SmallOrder(order.a,order.b,order.c) from Order as order where order.contact.name='crab'（結合了b問題）這樣我們根本就不需要擔心客戶的bt要求，他想怎么查詢訂單我都可以很容易的給他加上查詢條件。
最后就是我們的產品模塊，原來為了能夠最大限度的擴展，利用了萬能表的方式，這樣什么產品都可以定義出來，但是這樣的設計不利于做報表和查詢，現在可以利用Hibernate重新設計產品模塊，也可以很方便的萬能化，但是查詢和報表就可以很方便了。
總之，Hibernate給我們項目帶來了真真實實的好處，從開發效率和運行效率上都是，特別是可以使用面向對象的方式去操作數據庫，這樣可以很面向對象地寫企業程序，可以帶來開發時候真實地快樂：）
還有一個最大的體會是Hibernate很少違反我的直覺，很多時候我只是覺得這個特性Hibernate應該支持，然后就試驗，然后就成功了，根本不需要去看文檔，這個和Python的“最少驚奇”原則妙曲同工。
文章來源:
http://blog.donews.com/crabhn/archive/2006/02/24/739825.aspx