最早接觸Hibernate是在2004年，當時懷着忐忑和不安的心情來學習這門技術。經過這幾年的使用和研究，也積累了一定的經驗，下面就HQL和QBC查詢來談一下我從工作中得到的一些總結。
本文不會講什麼是Hibernate、什麼是ORM、更不會談怎樣使用HQL與QBC。本文的目的是讓大家對平常使用最多，也是最廣泛的與數據庫打交道的兩種方式，有一個新的認識。
恩，如果你還不知道Hibernate，大象建議你先去學一下再來看本文，如果你已經是這方面的高手，大可以關掉瀏覽器，千萬不要因爲本人的愚見，讓你對大象口誅筆伐，進行人身攻擊。
HQL和QBC都是查詢檢索的方式，最開始，我一直使用的都是HQL，因爲以前一直用的都是SQL，覺得這東西和SQL差不多，上手很快。後來又用QBC，因爲QBC是基於接口和類的對象化查詢，使代碼變得很清晰，很整潔。
下面是查詢用戶表中，id爲2，年齡等於21，並且名字以J開頭的兩種查詢語句，它們的結果都是一樣，只是不同的表現方式。
HQL:
Query query = session
.createQuery("from User u where u.id = 2 and u.age = 21 and u.name like 'J%'");
List list = query.list();
QBC：
Criteria criteria = session.createCriteria(User.class);
List list = criteria.add(Expression.eq("id", 2)).add(
Expression.eq("age", 21)).add(Expression.like("name", "J%"))
.list();
如果查詢再複雜一點，需要關聯多張表，那上面這個HQL語句就會顯得很複雜，比較難以閱讀。對於QBC來說，需要再加一個createCriteria()，返回一個criteria新實例，比如說，用戶表與帳號表關聯，需要根據帳號表中的帳號，開戶時間，金額等信息進行查詢，可以寫成下面的形式：
List list = criteria.add(Expression.eq("id", 2)).add(
Expression.eq("age", 21)).add(Expression.like("name", "J%"))
.createCriteria("account", "a").add(
Expression.eq("a.account_id", 112546)).add(
Expression.eq("a.start_date", "2008-8-30")).add(
Expression.eq("a.money_sum", 1000)).list();
account是用戶表中建的與帳號表的關聯對象屬性，a是別名。我爲了便於說明，用的都是固定值，並且條件判斷也都是eq（等於），其實在實際開發中，這是不可能的，這些值全都會被變量所代替。add方法也不用寫在一起，可以分開來，特別是在查詢中，需要對傳入的參數進行檢驗，這時就需要一個條件一個條件的往上加。
這樣看來，好像QBC比HQL要好一些，大象是這麼認爲的：HQL簡單、靈活，QBC整潔、方便，不能說誰好誰不好，否則大名鼎鼎的Hibernate爲什麼要支持這兩種檢索方式呢？
根據本人做開發的情況來看，在需要多表關聯查詢的時候，如果POJO類之間建立一對多或多對多這樣的關聯關係，效率是很低下的，就算你設置了延遲檢索，也會感覺很慢。而且在實際開發中，我還發現，在數據庫中建立外鍵是一件非常吃力不討好的事情，因爲很多時候出錯都是跟外鍵有關係，主要體現在修改和刪除。而POJO之間建立對象關係，則會增加編碼的複雜程度，提高出錯機率，另外還會增加用戶等待的時間。這是大象以前開發時所經歷過的，所以後來的項目中，對於數據庫中的每個表，只給一個流水號主鍵，不在建立其它的外鍵關係，而在POJO中，只設定最原始的屬性與表中的字段對應，對於需要做多表查詢的情況，建立視圖，把需要查詢的字段屬性與要在列表中顯示的字段屬性都放在視圖POJO中，這樣，不管是HQL還是QBC，一個類就可以解決問題，而且對視圖查詢可比使用表之間的關聯關係查詢要快很多。
在項目中，到底採取哪種檢索方式，關鍵還得看項目負責人。比如大象現在做的這個項目就規定了，必須使用QBC，而且除報表外，不準使用視圖。呵呵，這樣的情況，只能在POJO之間建立關聯關係了，不過能少建，我們還是會盡量的減少類之間的關聯，好在現在開發用的JDK是5.0的，因此我們可以使用註解的方式定義一些臨時對象屬性，這樣也省掉了以前必須得寫的hbm.xml文件，有時也採用仿視圖的方式用JavaBean來封裝一些對象和屬性。