大約一年以前，我為了學習一些Hibernate專業知識，因此我參加了一個Hibernate項目。從那時起，我一直在使用Hibernate框架下的JPA(Java持久API)實現，使用的思想仍就是一樣的。那個項目使用了一個數據庫，這個數據庫規模有些大，略顯落後，並且還被許多的應用程序共用。為了盡快加入到項目中，我開始學習一些Hibernate知識。從書本上的例子開始學習，感覺很簡單，學起來也很快，但是發現從零開始開發一個項目，並且控制它又是另外一回事了。試著在一個大型，復雜，被許多應用程序共用的數據庫上使用Hibernate就又完全不同了。弄清楚了我可能遭遇到的技術難點，我開始想別的招了，要盡快從另外的方向開始，克服困難。
在最終的學習和實踐中，我發現我還是學到了許多重要的東西，雖然我們的項目還沒有完全做完，但是我認為我們目前已經非常漂亮的應用了Hibernate/JPA的一些思想。現在我需要重新思考反省我所學到的東西，如下便是我學到的一些心得：
1）和數據庫管理員成為朋友
目前存在一個趨勢，就是一些Java開發者忽視數據庫管理員的重要性。這便犯了一個很大的錯誤，對於要取得任何的ORM（對象關系映射）技術的成功，和數據庫管理員保持一個良好的工作關系是至關重要的。有如下兩個原因：
單獨數據庫管理員雖然不能使Hibernate項目成功，但是他們通常可以讓這些項目失敗。
數據庫管理員對數據庫本身具有很好的洞察力，很好的職業習慣，告訴你一些易犯的錯誤和操作建議。我能記起這樣的很多例子，一個數據庫管理員的建議節約了我們很多的時間和提供給我們一個很好的解決方案。
在大多數情況下，擁有好的數據庫管理員，並且和他們保持良好的關系對你ORM（對象關系映射）工作至關重要。
2）從一開始使用（最好強制使用）好的命名標准
我們知道對命名標准的討論將會有爭議的，但是我們必須明確一件事情，我們的命名要讓我們的數據模型有意義，這能讓開發者使用起來簡單，以免他們迷惑。所以，如何命名實體和屬性是非常重要的。我有我喜歡命名標准，並且認為他們是最好的，但是在這裡我不想把他們強加於你們。最重要的是你自己做出決定使用什麼樣的命名標准，並且讓所有人使用它。實際上，不僅僅命名標准需要統一，其它的也需要（如，布爾型用“Y/N” 或者 0/1表示）。
3）不要試著映射所有的屬性
我們總是設法使用工具，如Dali來映射所有的東西，然後形成一張表格（一些表格有上百列 ！）。這最終會很麻煩。為什麼？因為我們使用的是共用的，先前的數據庫，有許多的字段是我們並不關心和從來不使用的。映射它們只會導致性能問題和造成混亂。
4）讓數據庫做自己擅長的工作
我們想有一個好的，清晰的數據模型，因此我們不惜任何代價寫一些額外的查詢語句來獲取對象相關數據，要麼使用存儲過程，要麼使用函數。這是做法是錯誤的，數據庫優勢在於存儲，而不是保持Hibernate創建或讀寫的數據。舉個例子，我們有一個對象，與之相關聯的有一個狀態。這個狀態在整個應用程序中都要用到，因此，它毫無疑問是要執行的，但是，我們不想每次都要單獨的寫一個查詢語句。這個問題在於，這個狀態是從一些統計計算中派生出來的，並且這些統計計算需要用到一對多的關系。每次從加載的對象中讀取數據的代價是非常高的。後來跟我們其中的一位數據庫管理員交流了一下，發現一個我們可以使用的sql函數能夠很快的獲得該狀態。我們使用@Formula來映射成一個狀態屬性，就能得到我們所需要的所有東西。這仍就是域模型的一部分，但是執行起來非常好。有時像這樣的一個折衷的辦法能夠起到很大的效果。
5）分解數據庫
在一開始，我就想在Hibernate中模型化整個數據庫。結果發現這是不切實際的，原因如下：
a)這是一項巨大的工程，並且要花費幾周的時間，而用戶根本看不到你做了什麼實際的工作。
b)我不可能在第一次就把它弄好，後繼的開發者無論如何都會修改它們的。
現在有一個趨勢，就是希望在開始之前，將所有的事情都進行映射，但是，當時你開始這麼做後，你不需在這上面花很多的時間。我後來發現一個好的辦法，就是將數據庫分解，工作的時候一塊一塊的進行，發現這很有幫助。
6）密切注意觸發器
密切注意數據庫觸發器有如下兩個原因：
a)在後台觸發器很隱蔽的執行了一些功能，讓你很是疑惑，不知道發生了什麼。
b)當你在Hibernate端需要復制一些東西的時候，觸發器會做一些手腳。之前我們好幾次沒有認識到這個教訓，導致我們丟失了很多數據，這些都是由觸發器引起的，這幾乎讓我們很是郁悶。
7）避免使用工具來自動生成你的模型
沒錯，這些工具的使用可以節約時間（雖然我們發現了Dali有一個很嚴重的bug,但是我們還是使用它），但是最後你不得不重新做很多的事情。其實手動也花費不了你很多的時間，當你親自做的時候，這可以讓你有機會熟悉那些數據。
8) 盡量多的使用命名查詢語句（NamedQueries）
雖然很容易寫查詢語句，但是在許多的情況下，使用NamedQueries會更好，這會有助於你完成兩件事情：
a)它能更加重用，因為被命名的查詢語句通常在代碼的重要地方。
b)你的查詢語句在開始的時候就是正確的，那麼在查詢語句中的錯誤更加容易發現。
要習慣這樣做需要花一些時間，但是這麼做是值得的。
9）預期管理
對於任何一種框架、技術、甚至觀念來說，這是非常重要的，要銘記在心。由於某些原因，人們傾向於專注某一個特征，這些特征實際上或許不存在，或許被誇大。有時它很小，很容易理解（舉個例子，理解一些實際的工作，需要在Hibernate中映射），有時我也不知道他們是如何管理實現一些概念（如Hibernate是如何管理計劃修正的）。無論如何，找到預期目標是什麼，然後管理它們是非常重要的。如果你的團隊認為Hibernate會使得數據庫管理員沒有用處，把他們解雇，那麼你將會有一個潛在的問題存在。
10）使用富域模型（rich domain modeling）
我所遇到的一件很悲哀的事情，就是在域對象僅僅是一個簡單的數據容器的時候，我要使用Hibernate，而像Hibernate這樣的工具讓我們以面向對象的方式來使用數據。簡單的映射數據只是讓我們停留在中途。當我本能的想到使用富域模型（rich domain modeling）的時候，我發現我們可以重用很多的代碼，我們的其它層變得不那麼混亂了，並且我們的代碼更加容易測試。
