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和資料建模，幾者共用，開發效率一定會有較大的提高。

Nhibernate分析之華山論劍篇

Nhibernate分析之華山論劍篇

Nhibernate分析之華山論劍篇

nhibernate架構分析

相關推薦