一、上章回顧

　　上章我們主要講述了系統設計規范與原則中的具體原則與規范及如何實現滿足規范的設計，我們也講述了通過分離功能點的方式來實現，而在軟件開發過程中的具體實現方式簡單的分為面向過程與面向對象的開發方式，而目前更多的是面向對象的開發設計方式。并且我們也講述了該如何通過設計手段去分析功能點及設計分離點，應該如何在設計的過程中分析的角度及如何去滿足設計規范與原則。首先我們通過下圖來回顧下上章要點：

二、摘要

　　本文將已架構的方式去分析分層結構中的業務層的設計，如何寫出來內聚度，高耦合的業務邏輯層，并且如何根據我們的項目中的個功能需要去設計業務層。我們本章將會通過幾種可能的業務層的設計模式去分析，并且分析每種設計模式的優點與缺點及每種設計模式的應用場景,并且結合一定的使用實例來講解，當然這些具體的內容都是自己在項目中的經驗與總結。錯誤之處，在所難免，本人抱著求真務實的態度，爭取寫好每一篇文章，錯誤之處還請大家匹配之處，如果您有好的意見或建議，可以及時跟我溝通，如果對系統架構中的設計規范與模式不了解，可以點擊這里查看上篇文章：系統架構師-基礎到企業應用架構-系統設計規范與原則[下篇]

　　本章講解的內容我們先看下圖中的幾個簡單模式：

三、本章大綱

　　1、上章回顧。

　　2、摘要。

　　3、本章大綱。

　　4、業務層設計分析。

　　5、幾種不同的業務設計模式。

　　6、本章總結。

　　7、系列進度。

　　8、下篇預告。

　　四、業務層設計分析

　　本節中將會對業務層的設計進行詳細的分析。

　　首先、我們知道業務層是一個系統中最核心的部分，業務層是實現系統業務功能的核心邏輯層。業務層我們通常說的BLL(Business Logic Layer)層，現在我們一般的稍微復雜一些的業務邏輯都是通過分層結構來構建一個應用系統，我想大家在組織業務邏輯功能時大部分的情況下是使用BLL層單獨負責相應的業務邏輯來實現的。有些應用可能業務邏輯層并不復雜，這是我們可以把問題簡單化，不用引入一些框架性的東西來提升系統的復雜度，但是有些業務規模較大，并且業務邏輯性較強時，可能使用好的業務設計模式帶來的優越性就顯而易見了。 我們大家都知道業務邏輯層主要是用來處理領域模型對象之間的邏輯關系的部分。我們都知道業務層的數據最終是要保存到數據庫中，我們在進行業務層設計時一般是在架構中的分層架構模式中出現的。我們知道分層結構中一般是將領域模型與底層數據訪問、表現層等進行分開組織，這樣可以讓系統結構上清晰，并且容易降低他們之間的耦合性。

　　其次、其實我們的很多操作都是可以在業務層來完成，比如說用戶的角色權限，數據驗證等一些基本的業務規則。當然這里說明業務層主要負責系統中的業務規則的實現。這里我們需要知道2個概念，就是對象模型與領域模型：下面我們說下這2者的區別。

描述對象模型與領域模型的區別。

　　***、業務邏輯層作為分層系統中的中間位置，業務模型是表現層與數據層之間的紐帶。當然一般我們在系統設計時，可能我們一般不會把領域模型中的領域實體作為分層之間的傳輸信息，因為一般來說領域模型中的實體不但包含實體的數據信息，并且包含實體的行為。可能我們在各層中只會用到實體的數據信息，那么無疑這時采用領域實體的形式進行傳輸，那么會增加系統的傳輸負載。當然這里就會出現我們平時所謂的3層模式中的Model層。當然Model層設計的主要作用就是實體數據的承載，其中并不包含任何行為。具體的行為通過數據訪問層來實現CRUD（DDL中的四個基本操作）的操作。

　　目前我們設計的分層結構中的對象模型中并不包含實體的行為。其實這里可以看作是比較好的設計方式，因為采用對象模型的方式進行數據傳輸時可以降低系統的耦合。當然我們也可以把領域實體看作是多個對象實體的組合并且包含這些對象實體之間的關系。所以我們在做系統架構時可能如何權衡就比較重要，具體是使用領域實體進行數據傳輸還是對象實體主要還是看業務的需要。

　　五、幾種不同的業務設計模式

　　首先我們在業務邏輯層設計時，必須首先確定是采用面向過程還是面向對象的模式來設計。 下面我們就將針對開篇介紹的幾種模式進行分別介紹，錯誤之處請大家批評指出。我們首先來講解過程式的2類邏輯層的架構模式。

　　過程式模式

　　1、事務腳本模式

　　事務腳本模式是面向過程的模式，那么我們就不會采用面向對象的設計思想。這種模式是將業務代碼映射到用戶的操作中。簡單的理解就是將用戶的每個操作都對應一個方法，那么這個方法就是我們這里講的事務腳本。 當然這里的“事務”就是指我們平時說的業務流程，“腳本”則是我們說的流程中的相應操作方法。這里

需要注意的是 ,不要認為數據庫操作的相應方法也屬于腳本中的內容，我們通常還是將數據訪問層單獨的書寫，只不過腳本中調用而已。通常，事務腳本模式中都是一系列的邏輯判定或者循環或其他方式，通過一系列的函數調用來實現業務流程的。通常來說一般業務比較單一或者不是很復雜的系統功能，通過該模式實現起來會比較簡單。而且如果業務流程中的變化較為頻繁的話不建議使用該模式來做。我們認為，我們對于這類簡單的功能，我們沒有必要花費較大的代價去設計領域模型和其他方面的考慮。事務腳本模式的一大優勢就是很簡單，沒有開始時的額外代價，它可以很好的進行快速的應用程序開發，一般情況下來說，如果一個項目的時間緊迫，邏輯簡單，并且使用強大的開發工具時，我們可以使用這樣的模式來進行，無論是成本還是開發效率上都非常客觀。

我們根據上面的介紹可能認為，事務腳本模式的可重用性不高，并且耦合性太高，適應性并不好，當時我們仍然可以通過我們好的設計來實現代碼的重用，我們可以在進行“腳本”編寫時將重用的部分抽象出來，寫一個單獨的函數，以達到復用的目的。事務腳本模式的一個重大缺點就是通過這樣的設計很容易造成代碼重復，通常來說我們很容易完成一系列的業務功能，但是隨著應用程序功能的增加，那么應用程序代碼會變成非常復雜的程序結構，當然我們可以通過重構去環節該模式的這一劣勢，當規模達到一定程度時，我們同樣沒辦法去完成重構工作。

通過上面的講述，我們對事務腳本模式有了初步的認識，那么下來我們看看我們在進行業務邏輯層設計時的詳細使用該模式的步驟及相關準則。

　　本圖描述了事務腳本模式的設計過程，那么基本上每個系統流程都可以通過這樣的流程來完成設計。下面我們就針對一個簡單的實例來講解下

　　如何通過這樣的設計流程來實現系統的功能。

　　我們這里以簡單的購物流程來講述。如何下一個訂單

　　首先、我們先來分析下用例：

　　我們知道注冊的會員可以通過將產品添加到購物車中，然后通過去付款模塊來進入支付系統，完成訂單。

　　其次、分析出事務。

一般來說購物的流程是這樣的流程。當然這里也不是標準的形式。

　　那么我們如何上述的幾個步驟的內容，去完成這個事務的流程。

public class BuyInfo  
　　{  
　　/// <summary>  
　　/// 購物車中的產品列表  
　　/// </summary>  
　private List<Product> proList = new List<Product>();  
　　public int CreateBuyCar(Product product)  
　　{  
　//事務開始  
　　this.BeginTranstion();  
　　//判定當前添加到購物車中的產品信息是否是自己發布的產品  
　　if (!this.IsCanBuy(product.PutOutID))  
　　return;  
　　//判定當前產品的庫存信息是否大于當前購買的數量;  
　　if(!this.IsLagerThenBuy(product.PutOutID))  
　　return;  
　　//添加產品到購物車  
　　proList.Add(product);  
　　//處理生成訂單信息  
　　int orderID= this.CreateOrder();  
　　//事務結束  
　　this.EndTranstion();  
　　return orderID;  
　　}  
　　/// <summary>  
　　/// 生成訂單  
　　/// </summary>  
　　/// <returns></returns>  
　　private int CreateOrder()  
　　{  
　　Order order = new Order(this);  
　　return order.CreateOrder();  
　　}  
　　/// <summary>  
　　/// 判定當前產品的庫存信息是否大于當前購買的數量  
　　/// </summary>  
　　/// <param name="p"></param>  
　　/// <returns></returns>  
　　private bool IsLagerThenBuy(int p)  
　　{  
　　return false;  
　　}  
　　/// <summary>  
　　/// 判定是否是自己發布的產品信息  
　　/// </summary>  
　　/// <param name="p"></param>  
　　private bool IsCanBuy(int p)  
　　{  
　　return false;  
　　}  
　　private void EndTranstion()  
　　{  
　　//TODO..  
　　}  
　　private void BeginTranstion()  
　　{  
　　//TODO..  
　　}  
　　} 

　　這里定義的是添加到購物車的流程，下面將給出如何將購物車中的產品信息添加到訂單中的具體流程。

　　public class Order  
　　{  
　　private BuyInfo info;  
　　public Order(BuyInfo buyInfo)  
　　{  
　　info = buyInfo;  
　　}  
　　public int CreateOrder()  
　　{  
　　//將BuyInfo購物車中的產品列表與訂單信息進行關聯。  
　　this.InitOrderInfo();  
　　//將訂單中的會員信息關聯  
　　this.InitOrderUserInfo();  
　　//將訂單中的收貨信息關聯。  
　　this.InitOrderReciveInfo();  
　　//將訂單中的支付信息關聯。  
　　this.InitOrderPayInfo();  
　　//生成訂單。  
　　}  
　　/// <summary>  
　　/// 將購物車中的產品添加到數據庫中  
　　/// </summary>  
　　private void InitOrderInfo()  
　　{  
　　throw new NotImplementedException();  
　　}  
　　/// <summary>  
　　/// 初始化訂單的支付信息  
　　/// </summary>  
　　private void InitOrderPayInfo()  
　　{  
　　throw new NotImplementedException();  
　　}  
　　/// <summary>  
　　/// 初始化訂單中的收貨信息  
　　/// </summary>  
　　private void InitOrderReciveInfo()  
　　{  
　　throw new NotImplementedException();  
　　}  
　　/// <summary>  
　　/// 初始化訂單的買家信息  
　　/// </summary>  
　　private void InitOrderUserInfo()  
　　{  
　　throw new NotImplementedException();  
　　}  
　　} 

　　通過上面的形式基本上就完成了簡單事務腳本模式的構建，當然我們也可以將所有的一系列的腳本封裝到一個類里面，通過靜態方法的方式來訪問也是可以的。只是組織方法的形式不同。當然我這里提高了，通過將腳本封裝到一個類里面，通過靜態方法的形式或者實例方法的形式都是可以的，那么我們來講講什么時候封裝成靜態方法，什么時候封裝成實例方法。

　　我們如何將數據傳入給實體腳本呢，通常我們是通過前面我們說的對象實體來完成的，因為數據對象實體只是包含實體的數據信息，并不包含具體的行為。

　　那么我們來簡單說說對象實體中的信息及格式，我想大家用過分層結構中的Model層的都會比較的清楚，下面我們看看，不詳細介紹了：

　　public class Product  
　　{  
　　private int putoutID;  
　　public int PutOutID  
　　{  
　　get 
　　{  
　　return this.putoutID;  
　　}  
　　set 
　{  
　　this.putoutID = value;  
　　}  
　　}  
　　private int productID;  
　　public int ProductID  
　　{  
　　get 
　　{  
　　return this.productID;  
　　}  
　　set 
　　{  
　　this.productID = value;  
　　}  
　　}  
　　private int productName;  
　　public int ProductName  
　　{  
　　get 
　　{  
　　return this.productName;  
　　}  
　　set 
　　{  
　　this.productName = value;  
　　}  
　　}  
　private int productUnit;  
　　public int ProductUnit  
　　{  
　　get 
　　{  
　　return this.productUnit;  
　　}  
　　set 
　　{  
　　this.productUnit = value;  
　　}  
　　}  
　　private int productClass;  
　　public int ProductClass  
　　{  
　　get 
　　{  
　　return this.productClass;  
　　}  
　　set 
　　{  
　　this.productClass = value;  
　　}  
　　}  
　　} 

　　我們看到了主要是通過get；set訪問器來實現的。

　　總結：業務邏輯層是將表現層觸發一系列事務分別實現，那么對業務邏輯層的建模其實就是對事務的具體實現，將事務映射到業務邏輯層中的不同方法上，一般來說事務代碼維護起來比較難以維護，重用性低，難以理解。

　　2、表模塊模式

　　表模塊模式是對事務腳本模式的實踐總結并優化而提出的新模式。相比而言，表模塊模式結構性更強，總體來說，表模塊就是就是將數據庫中的某個表上的所有可能的操作都寫在一個類文件中，這個類文件中定義了該數據庫表對應的所有的業務方法。表模塊類是一個容器，它內部包含了類的數據信息和相應的行為。表模塊是映射數據庫表的關系，因此表模塊對應的是數據集合，那么無法將數據庫表中的某個行記錄進行區分，只能通過集合中的鍵或者索引來訪問行記錄的信息。

表模塊模式由于是在事務腳本模式發展的更有結構化的模式，那么可以說表模塊模式雖然是面向過程的模式，但是它朝面向對象的模式已經邁了很大的一步，我們知道,在將對象模型中的數據保存到關系數據庫中時，需要使用相關的ORM工具去完成相應的轉換。我們知道面向對象模型能夠很靈活、更好的對領域模型建模。當然，表模塊模式仍然關注的是方法，而不是對象。

通常我們在更好的結構設計指導的同時，那么我們需要考慮更多的規則，那么意味著我們需要書寫更多的代碼。表模塊模式的具體實例可以參考Visio Studio中的提供的DataSet和dataTable。表模塊在處理簡單的實體時具有很好的優勢，但是當實體較復雜時，或者實體之間的關系緊密時無法很好的處理。下面我們來看看一個簡單的例子來說明表模式的使用。我們這里還是以剛才事務模型中的購買流程來講解。

　　數據庫表與表模塊類的映射關系是通過.NET提供的內存數據對象DataSet、

　　DataTable來實現。

　　public class Order  
　　{  
　　private System.Data.DataTable _orderItems;  
　　private DataSet _ds;  
　　public Order(DataSet ds)  
　　{  
　　_ds = ds;  
　　}  
　　/// <summary>  
　　/// 返回訂單對應的所有產品信息  
　　/// </summary>  
　　/// <returns></returns>  
　public DataTable Products()  
　　{  
　　return _orderItems;  
　　}  
　　/// <summary>  
　　/// 返回當前索引號的訂單信息  
　　/// </summary>  
　　/// <param name="index"></param>  
　　/// <returns></returns>  
　　public DataRow GetRow(int index)  
　　{  
　　return _ds.Tables[0].Rows[index];  
　　}  
　　/// <summary>  
　　/// 根據訂單的ID返回訂單的信息  
　　/// </summary>  
　　/// <param name="id"></param>  
　　/// <returns></returns>  
　　public DataRow GetRowByID(int id)  
　　{  
　　return _ds.Tables[0].Select("id=" + id.ToString());  
　　}  
　　public int Update(int orderID)  
　　{  
　　return 0;  
　　}  
　　public int Delete(int orderID)  
　　{  
　　return 0;  
　}  
　　public int Insert(int orderID)  
　　{  
　　return 0;  
　　}  
　} 

　　我們這里的數據如果發生變化時，我們如何將變化了的內存中的datatable或者dataset持久化到數據庫中呢，ADO.NET為我們提供了dataadapter，通過這個適配器我們完成datatable中的數據持久化到數據庫表中。具體的形式就是上圖中的流程，UI層通過數據請求方法，然后表模塊層中有相應的方法，將發送數據請求訪問數據庫，然后數據庫返回相應結果通過datatable或dataset來初始化表模塊類中的數據信息，然后返回給UI層相應的數據信息，然后綁定后顯示。

　　總結：表模塊模式相比事務腳本模式。是我們推薦的使用模式。并且VS中自動繼承了相應的datatable 與datas的相應的圖形化設計方法，很方便的使用。并且內部.NET framework 內置了相應的操作方法可以迅速的實現交互，在過程式模式中無疑是使用表模塊模式是***方案。表模塊模式更關注的是與數據庫表的映射關系，那么可以說表模塊模式中包含了數據模型。有一些面向對象的味道，不過表模塊模式中并不關注業務。

　　對象式模式

　　我們來講述下面向對象的模式中的2種方案

　　1、活動記錄模式

　　我們知道業務邏輯層中的業務邏輯才是系統的核心，那么我們更關注的是業務邏輯或者領域邏輯。因為我們必須關系實體之間的交互。我們如果對領域模型建模。我們需要使用面向對象的角度去分析需求。 我們先來看看基于對象模式的活動記錄模式。

　　活動記錄模式是在表模塊模式的基礎上，將表模塊的粗粒度的基于數據集上的映射細化到表中行記錄的細粒度的映射，并且映射的對象中包含相應的數據庫表中的數據信息，并且包含對象的行為。例如，我們現在如果想將產品表中的產品信息映射到數據庫中的表product中的行記錄，那么我們需要構建一個product類，該類中的屬性與product表中的列信息一一對應。并且product類中還包含該對象所有的行為。例如CRUD的操作，其他的行為等。

　　首先我們需要知道活動記錄的優勢是什么？首先我的理解就是活動記錄模式容器理解，簡單，并且目前有很多的框架支持這樣的模式。首先就像Linq、Castle框架都是采用這樣的模式。。一般情況下，活動記錄模式在關系型模型中可以很好的支持。如果在應用程序中不使用關系型模型來設計業務層的話，那么需要我們人工來組織，協調活動記錄與數據模型之間，其實這個就可以簡單的理解為數據映射，一般的ORM框架中都提供這樣的功能。

　　我們需要知道，如果活動記錄模式下的對象發生改變了，那么數據庫也得跟著修改，或者數據庫表發生改變了，那么你不得不修改對應的活動記錄對象及相關代碼。

　　總而言之，如果我們在使用活動記錄模式的過程中如果不能保證對象模型與數據模型之間的對應關系，那么我們將會很快失控，那么領域模型顯然能夠解決這樣的問題。下面我們來看下活動記錄模式的實例。我們還是以購物流程為例。

　　public class Order  
　　{  
　　private int _orderID;  
　　public Order(int orderID)  
　　{  
　　_orderID = orderID;  
　　}  
　　public int OrderID  
　　{  
　　get 
　{  
　　return this._orderID;  
　　}  
　　set 
　　{  
　　this._orderID = value;  
　}  
　　}  
　　private int _orderState;  
　　public int OrderState  
　　{  
　　get 
　　{  
　　return this._orderState;  
　　}  
　　set 
　　{  
　　this._orderState = value;  
　　}  
　　}  
　　/// <summary>  
　　/// 返回訂單對應的所有產品信息  
　　/// </summary>  
　　/// <returns></returns>  
　　public List<Product> Products()  
　　{  
　　return this.GetProducts();  
　　}  
　　private List<Product> GetProducts()  
　　{  
　　List<Product> lists = new List<Product>();  
　　return lists;  
　　}  
　　public int Update()  
　　{  
　　return 0;  
　　}  
　　public int Delete()  
　　{  
　　return 0;  
　　}  
　　public int Insert()  
　　{  
　　return 0;  
　　}  
　　} 

　　我們可以看到區別，從原來的表模式中的通過ADO.NET提供的內存集合表中的形式，修改為通過對象中的屬性的形式來保存對象的數據信息，顯然這就是表模式與活動記錄模式的***區別。不過實現的思想上差別不大。

　　我們都知道數據庫表之間如果有關聯的話，那么我們通過的是外鍵的形式來進行關聯，那么我們在活動記錄中一般如何來標識某個類對應的外鍵對象信息呢。

　　那么我們在訂單中可能會有對應的用戶ID，不過在不同的框架中可能對外鍵對應的對象信息的存儲方式會有所不同，有些框架中在外鍵對象上通過屬性的方式返回對象的實例的應用。簡單來說下這2種方式的區別：例如：

　　public class Order  
　　{  
　　private int _orderID;  
　　public Order(int orderID)  
　　{  
　　_orderID = orderID;  
　　}  
　　public int OrderID  
　　{  
　get 
　　{  
　　return this._orderID;  
　　}  
　　set 
　　{  
　　this._orderID = value;  
　　}  
　　}  
　　private int _orderState;  
　　public int OrderState  
　　{  
　　get 
　　{  
　　return this._orderState;  
　　}  
　　set 
　　{  
　　this._orderState = value;  
　}  
　　}  
　　private int _userID;  
　　public int UserID  
　　{  
　　get 
　　{  
　　return this._userID;  
　}  
　　set 
　　{  
　　this._userID=value;  
　　}  
　　}  
　} 

　　另外一種形式。直接將User用戶的完整對象引用實例返回。

　　public class Order  
　　{  
　　private int _orderID;  
　　public Order(int orderID)  
　　{  
　　_orderID = orderID;  
　　}  
　　public int OrderID  
　　{  
　　get 
　　{  
　　return this._orderID;  
　　}  
　　set 
　　{  
　　this._orderID = value;  
　　}  
　　}  
　　private int _orderState;  
　　public int OrderState  
　　{  
　　get 
　　{  
　　return this._orderState;  
　　}  
　　set 
　　{  
　　this._orderState = value;  
　　}  
　　}  
　　private UserInfo _userinfo;  
　　public UserInfo User  
　　{  
　　get 
　　{  
　　return this._userinfo;  
　　}  
　　set 
　　{  
　　this._userinfo=value;  
　　}  
　　}  
　} 

　　上面我們看到了活動記錄模式的簡單使用方式，當然我這里沒有說是寫出來可以運行的實例代碼。只是簡單的顯示了，使用這些模式可能的用法，當然如果大家有更好的理解或者用法可以一起交流。當然活動記錄模型一般就能滿足我們的系統功能，如果說針對業務復雜的領域，那么必須設計領域模型去完成相應的業務邏輯層的設計。下面我們將來介紹領域模型模式的相關實例。

　　2、領域模型模式

　　我們前面講解的幾類模式，其實說白了都是以數據為中心進行抽象與設計的形式，當然采用這樣的形式無疑是以業務中的數據為中心，并不是關心的業務本身。以數據為核心的設計方法一般流程如下：

一般來說我們目前主流的方式都是這樣的順序來執行。當然通過這樣的方式的確一般的簡單應用當然都是沒有太大的問題。有的時候我們需要同時關系對象的數據與行為，那么顯然以數據為核心的情況就會顯得力不從心，當然簡單的系統時不會有太大的體現，當時當系統的規模上升到一定的程度時，哪怕添加一些新的需求時，對系統的影響都是致命的。

　　領域模型關注的是系統期待的行為及系統正常工作所需要的數據流。一般我們在設計領域模型的時候需要這個領域的專家協助，***以類的形式呈現出來。當然

　　領域模型模式中的實現方式，大家都知道的就是有名的DDD(領域驅動設計)。

　　領域模型設計的最終目標就是與系統的概念模型匹配起來。我們可以把領域模型看作是概念模型的物理模型。在一個項目中可以說領域模型是最重要的，最關鍵的部分。

　　領域模型可以看作是一系列對象之間的交互。領域模型中的每一部分都需要用一個帶有行為的類來表示。這個怎么理解呢，請看圖：

訂單信息對象首先會與訂單中的產品對象有交互關系，產品項與產品分類有交互關系。訂單信息與用戶買家有交互關系，訂單的其他信息(物流信息、支付信息等)有交互關系。

　　例如我們常說的記錄的系統日志，不管是錯誤日志還是其他的所有系統中的日志，那么我們建議的方式采用AOP的方式來處理。那么我們來看看具體的代碼實現：

　　//定義接口  
　　public interface ILog  
　　{  
　　//具體的寫日志的方法  
　　void WriteLog();  
　　}  
　　//簡單實現  
　　public class BaseWrite : ILog  
　　{  
　　#region ILog 成員  
　　/// <summary>  
　　/// 基本的書寫日志的方法  
　　/// </summary>  
　　public void WriteLog()  
　　{  
　　try 
　　{  
　　Write.WriteLog(this);  
　　}  
　　catch 
　　{  
　　}  
　　}  
　　#endregion  
　　} 

　　具體調用的寫日志的方法：

　　public class Write  
　　{  
　　public static bool WriteLog(ILog log)  
　　{  
　　//具體的寫如日志的方法。  
　　return true;  
　　}  
　　}  
　　具體相關的產品類與產品分類對象的使用：  
　　/// <summary>  
　　/// 產品類  
　　/// </summary>  
　　public class Product : BaseWrite  
　　{  
　　//產品的相關屬性  
　　public int ProductID { get;set;}  
　　public int ProductName { get;set;}  
　　public int ProductClassID { get;set;}  
　　public int ProductSort { get;set;}  
　　public int ProductIsEnable { get;set;}  
　　//產品類相關的方法  
　　public List<Product> GetAll()  
　　{  
　　return new List<Product>();  
　　}  
　　}  
　　public class ProductClass : BaseWrite  
　　{  
　　//產品分類相關屬性  
　　public int ProductClassID { get;set;}  
　　public int ProductClassName { get;set;}  
　public int ProductClassCategory { get;set;}  
　　public int ProductClassSort { get;set;}  
　　public int ProductClassIsEnable { get;set;}  
　//產品分類相關的信息  
　　public List<ProductClass> GetAll()  
　　{  
　　return new List<ProductClass>();  
　　}  
　　} 

　　我們看到了在活動記錄模式中會將數據訪問層的代碼寫在該層，但是領域模型中一般不會出現這樣的代碼。領域模型中只關心跟業務流程相關的內容，具體的數據持久化之類的內容一概不關心。領域模型中是一系列的對象之間的交互，那么我們可能會關心，如何將領域模型中的這些對象的狀態進行保存呢，那么就會牽扯到對象模型到關系型數據庫中持久化的個問題了，在持久化的問題上，我們可能有幾種選擇，一種是采用現有的ORM框架去實現對象數據的自動持久化，當然這是一種解決辦法。有時候我們是通過手動的方式來進行持久化，可能就不存在這樣的問題。

　　我們通常在持久化數據的問題上我們希望能做到持久化的透明性，這樣就可以說具體的業務層不需要書寫持久化的操作代碼，當然我們現在設計的時候可能都是要么是通過特性來實現持久化，或者是通過繼承基類的方式來做持久化的操作，那么可能帶來如下的問題。

　　一般我們知道，一個類如果想不寫相應的持久化代碼還能實現持久化的話，那么我們只能通過動態的注入持久化代碼的方式來實現這樣的持久化透明的方案，微軟的EntityFrameWork2.0中的POCO中的ORM方案，就是通過這樣的方式來實現的。我們更關心的是代碼應該放在何處，是在領域模型中還是領域模型外呢，當然目前的一些常見的框架中已有實現方案，其中大家熟知的NHibernate就是持久化透明的方式，大家如果感興趣可以參考NHibernate的實現思路來做。一般對于這種動態注入代碼的這樣的方案，這里簡單介紹下可能的實現，由于.NET framework 中提供了一個派生自特性類型的代理類，通過代理類來動態的將這個類的相關功能追加到指定的對象中，這就是所謂的動態代理，當然針對某個特定的類型這樣來做，WCF也是通過代理類的方式來實現這樣的動態插入的形式。

　　六、本章總結

　　本章主要是對業務層建模的不同的架構模式進行了相應的總結及簡單說明，可能某些地方說明不是特別的清晰，當然我也是將平時自己的業務開發中的一些經驗和總結，部分內容是參考以前看的書上的內容，不足之處還請大家多多的指點，還有請感興趣的朋友一起交流領域模型的設計，包括持久化的透明的實現方案等，歡迎大家多提意見和建議。本人抱著學習和寧缺毋濫的原則，寫好每一篇，可能看過這方面資料的同仁當溫習下相關內容，沒有看過同仁希望對你們有幫助，那就是我***的動力。

　　八、下篇預告

　　下一篇我們將會開始講解軟件設計中最重要也是最基本的技能-設計模式，希望大家多多提出已經，后面3篇我們將會講解如何在項目中使用設計模式及使用設計

　　模式需要注意的事項,將會舉例說明每個設計模式可能出現的場景。希望大家持續關注！

　　作者：CallHot-何戈洲

　　出處：http://www.cnblogs.com/hegezhou_hot/

　　關于作者：專注于微軟平臺項目架構、管理和企業解決方案。熟悉設計模式、極限編程、架構設計、敏捷開發和項目管理。現主要從事WinForm、ASP.NET、等方面的項目開發、架構、管理工作。如有問題或建議，請多多賜教！

【編輯推薦】

1. 系統架構師談企業應用架構之開卷有益
2. 系統架構師談企業應用架構之系統建模1
3. 系統架構師談企業應用架構之系統建模2
4. 系統架構師談企業應用架構之系統建模3
5. 系統架構師談企業應用架構之系統建模4
6. 系統架構師談企業應用架構之系統設計規范與原則1
7. 系統架構師談企業應用架構之系統設計規范與原則2
8. 系統架構師談企業應用架構之業務邏輯層