再談商務邏輯架構模式(事務指令碼，表模組，活動記錄，領域模型)

　　前幾天寫過一遍博文：商務邏輯架構模式(事務指令碼，表模組，活動記錄，領域模型) ，此文僅對常用的設計方式進行了一個大概的描述，感覺意猶未盡。經過幾天的研究查證與思考，又有些新的認識。

     雖然說這是四種獨立的架構模式，但是他們之間並不是毫無關聯的。除去在大型軟體中很少使用的表模組，事務指令碼與活動記錄經常交叉使用，活動記錄與領域模型也是互連有無。先說前者。

     活動記錄的優點很多，缺點也很明顯。最大的缺點就是由於是一張表對應一個模型，業務操作基本上都是基於單表的。當發生跨表邏輯時，就無法應付了，這時只好求助於事務指令碼，有時直接在Model裡寫事務指令碼，有時則在Model的上方建立一個XXXHandler或XXXManage來實現事務指令碼。如果對象間的關聯越來越多, 你的事務指令碼越來越龐大, 重複的代碼越來越多，項目就不可控了。

    對於領域模型，其構建模式並不是一成不變的，其很多變種就與活動記錄比較類似。常規的方式，是領域模型直接與資料庫映射，中間沒有其它層。但是也有這樣一個變種，在資料庫與領域模型間加入實體層，每一個實體對應一張表，領域模型以繼承或重新編寫的方式構建於實體之上。實體僅有資料，其CRUD由上層或其它對象完成，或者實體可以自行實現自己的CRUD，領域模型則通過操作各個實體的CRUD來完成商務邏輯。後面的一種架構方式，不就很象活動記錄+領域模型的架構嗎

    下面再繼續看看領域模型。如：

 

    在整個軟體架構過程中，BO（業務對象）通過DAO（Data Access Objects）操作PO（持久對象）來實現商務邏輯。對於VO（頁面展示對象），在單表情況下多是直接展示PO，多表情況下多是將多個PO對象合并成一個DTO（資料轉送對象）再進行展示。對於實體僅有資料，其CRUD由上層或其它對象完成的這種情況，BO包含DAO對象。對於實體自行實現自己的CRUD，BO與PO對象都包含DAO對象。

    具體到技術層面的選擇，ActiveRecord能很好的實現活動記錄模式，NHibernate對於活動記錄與領域模型都有很好的支援，園子裡的MySoft也是一個比較有特點的集活動記錄與事務指令碼於一體的架構，微軟的企業庫與園子裡的yueue.ADOKeycap則是很好的事務指令碼架構。

    其實對於這些架構的問題，我還有很多細節方面的疑問，各位高手看過後如果發現我說錯了，盡情拍磚糾正，讓我在思想碰撞的火花中成長。

 

參考的文章：

物件導向的NHibernate資料查詢語言-HQL

 

PO BO VO DTO POJO DAO概念及其作用（附轉換圖） 

 

java術語（PO/POJO/VO/BO/DAO/DTO）

ActiveRecord 模型