Nhibernate分析之華山論劍篇

    原來一直使用代碼產生，包括CodeSmith和天平兄的CodeMatic。最近打算系統學習一下Nhibernate，經過簡單的一點探索，發現ORM和代碼產生真是個有千秋。本文側重比較一下ORM和代碼產生二者的優缺點，讓二者華山一比高下，目的為去偽存真，使二者能夠相輔相成。從而更好的提高開發效率。
    本文從下面三個層面對ORM（以NHibernate為首發的O陣營) 和代碼產生(以CodeMatic為首發的C陣營)進行比較：
 1）針對資料庫二者的架構層次上的異同
 2)  針對應用程式二者在使用和配置上的異同
 3)  針對商務邏輯二者在對變化和複雜度上支援度的異同。
   下面就具體針對這三個層面做一下具體分析，這些分析都來源於自己開發中的一些經驗和心得，有些是正確的，有些也存在這樣那樣的問題。寫出來，希望的也只是能拋磚引玉，得到更多朋友，兄弟的協助和支援。
1) 針對資料庫二者在架構層次上異同
首先看一下下面這張圖：

ORM針對資料庫是由上而下的關係，也就是說ORM並不依賴於資料庫。他可以完全從關聯式資料庫中將程式員解放出來，需要程式員小心呵護的是傳遞給nhibernate的persistent object。這看起來更加OO，而代碼產生恰恰相反，代碼產生依賴於關聯式資料庫。它總結資料庫操作的一些共性，將本來需要程式員手寫的代碼自動產生出來。從OO的角度來說，代碼產生的過程並不體現OO思想，但根據模版或者軟體作者的一些邏輯。產生出來的代碼卻可能具有很好的OO思想。針對資料庫來說，ORM是自頂向下的，代碼產生則是自下而上。二者方向恰好相反。
2）針對應用程式二者在使用和配置上的異同
nhinernate的使用需要在原有系統上添加對nhibernate.dll和其他一些相關的dll的引用，而代碼產生則不然，代碼產生是在另外的一個軟體中，通過指定資料庫來產生用於操作資料庫的檔案，將這些檔案添加到項目中的時候才可以正常使用。nhibernate最讓人頭疼的就是配置和對應檔的編寫。而代碼產生，如果需要完成複雜的邏輯和自訂的業務，需要編寫CodeSmith等軟體的模版，這些模版的編寫也不是一件簡單的事情。從使用和配置上看，二者的異同在於

	使用方法	引用方法	設定檔
nhibernate	系統內	需要添加相關引用	需要編寫大量的配置和對應檔。
codematic	系統外	不需要添加引用	業務簡單時不需要配置，複雜時需要編寫自訂模版

3）針對商務邏輯二者在對變化和複雜度上支援度的異同
  假如原有一個User表，這個表已經運行了一段時間。但目前需要在User表裡面添加一個可為null的欄位:BirthDay,二者對此需求的響應各自是應該是怎麼樣的呢？

	資料庫改動	配置改動	代碼更改
nhibernate	無需	需要對應檔中添加對BirthDay的映射	更改User類，添加屬性BirthDay
codematic	需要在User表裡面添加一個BirthDay欄位	不需要更改	最佳使用狀態下需要從資料層到商務邏輯層重建代碼，如果以前有改動，則需要手動添加BirthDay向伽相關代碼

針對於單表操作，二者都比較簡單，但是當業務變得複雜的時候，二者在表現力如何呢？比如現在有這樣一種應用環境，計算和維護職員和工資，需求：1）列出所有職員 2）列出某個職員的某月的工資資訊 3) 統計某個員工在第2個季度的總工資。4）計算上半年公司支付給員工的總工資。其中包括已離職人員的工資。
在這樣一種應用環境下，分別討論二者如何應付

	資料表	業務對象	設定檔	業務對象的使用
nhibernate	無需建立	手動編寫User,Salary業務對象。	需要編寫設定檔，標示業務對象的主從關係	在二者差生圍度和關聯時，內建支援
codematic	需要建立User和Salary表，並指定主從	不需	不需	產生關聯和圍度時，需要手工更改資料底層和上層業務代碼

   總結，ORM和代碼產生二者各有各自的好處，但綜合考慮ORM更符合OO的口味，而代碼產生則比較靈活，可以應用到除了資料庫操作的其他方面。比如產生nhibernate需要的對應檔等。加上原有的URM和資料建模，幾者共用，開發效率一定會有較大的提高。