原來一直使用代碼生成包括CodeSmith和CodeMatic最近打算系統學習一下Nhibernate經過簡單的一點探索發現ORM和代碼生成真是個有千秋
本文側重比較一下ORM和代碼生成二者的優缺點讓二者華山一比高下目的為去偽存真使二者能夠相輔相成從而更好的提高開發效率
本文從下面三個層面對ORM（以NHibernate為首發的O陣營） 和代碼生成（以CodeMatic為首發的C陣營）進行比較
）針對數據庫二者的架構層次上的異同
） 針對應用程序二者在使用和配置上的異同
） 針對業務邏輯二者在對變化和復雜度上支持度的異同
下面就具體針對這三個層面做一下具體分析這些分析都來源於自己開發中的一些經驗和心得有些是正確的有些也存在這樣那樣的問題寫出來希望的也只是能拋磚引玉得到更多朋友兄弟的幫助和支持
） 針對數據庫二者在架構層次上異同
首先看一下下面這張圖
ORM針對數據庫是由上而下的關系也就是說ORM並不依賴於數據庫他可以完全從關系數據庫中將程序員解放出來需要程序員小心呵護的是傳遞給nhibernate的persistent object這看起來更加OO而代碼生成恰恰相反代碼生成依賴於關系數據庫它總結數據庫操作的一些共性將本來需要程序員手寫的代碼自動生成出來從OO的角度來說代碼生成的過程並不體現OO思想但根據模版或者軟件作者的一些邏輯生成出來的代碼卻可能具有很好的OO思想針對數據庫來說ORM是自頂向下的代碼生成則是自下而上二者方向恰好相反
）針對應用程序二者在使用和配置上的異同nhinernate的使用需要在原有系統上添加對nhibernatedll和其他一些相關的dll的引用而代碼生成則不然代碼生成是在另外的一個軟件中通過指定數據庫來生成用於操作數據庫的文件將這些文件添加到項目中的時候才可以正常使用nhibernate最讓人頭疼的就是配置和映射文件的編寫而代碼生成如果需要完成復雜的邏輯和自定義的業務需要編寫CodeSmith等軟件的模版這些模版的編寫也不是一件簡單的事情從使用和配置上看二者的異同在於使用方法引用方法配置文件nhibernate系統內需要添加相關引用需要編寫大量的配置和映射文件codematic系統外不需要添加引用業務簡單時不需要配置復雜時需要編寫自定義模版
）針對業務邏輯二者在對變化和復雜度上支持度的異同
假如原有一個User表這個表已經運行了一段時間但目前需要在User表裡面添加一個可為null的字段BirthDay二者對此需求的響應各自是應該是怎麼樣的呢？
數據庫改動 配置改動 代碼更改nhibernate 無需 需要映射文件中添加對BirthDay的映射 更改User類添加屬性BirthDaycodematic 需要在User表裡面添加一個BirthDay字段 不需要更改 最佳使用狀態下需要從數據層到業務邏輯層重新生成代碼如果以前有改動則需要手動添加BirthDay向伽相關代碼針對於單表操作二者都比較簡單但是當業務變得復雜的時候二者在表現力如何呢？比如現在有這樣一種應用環境計算和維護職員和工資
需求
）列出所有職員
）列出某個職員的某月的工資信息
） 統計某個員工在第個季度的總工資
）計算上半年公司支付給員工的總工資其中包括已離職人員的工資
在這樣一種應用環境下分別討論二者如何應付數據表 業務對象 配置文件 業務對象的使用nhibernate 無需創建 手動編寫UserSalary業務對象 需要編寫配置文件標示業務對象的主從關系 在二者差生圍度和關聯時內置支持codematic 需要創建User和Salary表並指定主從 不需 不需 產生關聯和圍度時需要手工更改數據底層和上層業務代碼
總結ORM和代碼生成二者各有各自的好處但綜合考慮ORM更符合OO的口味而代碼生成則比較靈活可以應用到除了數據庫操作的其他方面比如生成nhibernate需要的映射文件等加上原有的URM和數據建模幾者共用開發效率一定會有較大的提高
From:http://tw.wingwit.com/Article/program/Java/ky/201311/27948.html
