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

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

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

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

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

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

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

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

參考的文章：

面向對象的NHibernate數據查詢語言-HQL