閱讀目錄：
- 1.背景介紹
- 2.簡單介紹表模塊模式、事務腳本模式
- 3.正確的編寫表模塊模式、事務腳本模式的代碼
- 4.總結
1.背景介紹
要想正確的設計系統架構就必須能正確的搞懂每個架構模式的用意，而不是胡子眉毛一把抓。現在有一個現象是什么呢，項目的結構從表面上看是很不錯，層分的很合理，其實對業務系統來說也就那么幾種層設計方法，但是現在很多項目的邏輯架構的設計不是理想，有很多概念大家並不是很了解，當然也許每個人對技術的追求不同罷了。不管你追求不追求，事實我們還是要去往正確的方向努力才對的。
很多人包括我自己在內，都是寫過很多年的過程式的代碼，層對我當年來說就是個擺設而已，最典型的問題就是我們總是將表模塊模式和事物腳本模式一起混着使用，什么意思呢，就是說我們都會使用一些代碼生成器來根據數據庫中的表來生成三層架構中的業務層和數據層，有些比較好的代碼生成器也可以幫你把UI層中的部分視圖也生成好，確實很強大，有些場合下這是一中最合適的過程。
但是現在的系統已經不在是那樣的了，其中重要的一點就是業務復雜了，如果我們還稀里糊塗的編寫着代碼，最后只會成為你或者團隊的技術債務。
2.簡單介紹表模塊模式、事務腳本模式
我們簡單了解一下這里所謂的“表模塊模式、”事務腳本模式“到底是什么樣子的模式，最關鍵是你也許就知道了你目前所使用的業務層架構風格是什么模式，強調一下“表模塊模式”、“事物腳本模式”都是業務層的構架模式。
表模塊模式：
簡單講就是你數據庫中的每個表對應着業務層中的一個對象定義，如果你有一個Product表，那么你在Business Layer中就有一個Product.cs文件，當然這不是絕對的，你也可以將庫中的視圖也定義一個類型，如，OrderProduct.cs，也是可以的。然后每個類中的所處理的邏輯都是跟這張表相關的，你在Product.cs中的代碼就不要包含Order.cs中的代碼了。目前來看是有的，因為現在大部分的項目都是在寫着使用過程式的代碼，也就是事物腳本模式，這樣難免會將其他類型中的代碼寫到本類中。
事物腳本模式：
事務腳本模式就是過程式的代碼，只不過它的指標就是每一個代碼段獨立完成一個業務單元，而不是到處都是過程代碼，事物腳本模式還是很強調邏輯的統一性的。
使用此模式進行寫代碼時，你就不要單純的使用數據庫中的表名來定義業務類了，因為你是使用事務腳本模式的，你需要站在業務角度來規划你的業務層中大概包含哪些業務概念，然后使用這個業務概念來命名你的類。比如：UserOrder，UserOrder，類似這樣的定義，當然這里只是個假設而已，你不要站在數據庫的腳本來設計業務層就行了，這樣你就起碼不會使用到很細粒度的類型，哪怕下一次迭代進行重構也是可以的。
3.正確的編寫表模塊模式、事務腳本模式的代碼
這篇文章的重點就是本節，我們將了解一下這兩種模式的代碼到底該如何編寫。
說代碼如何編寫似乎有點讓人覺得不是很禮貌，其實我們大部分的代碼寫的都是正確的，但是如果我們將有些代碼稍微的羅一下位置就會明顯不一樣。
我們來看一個小例子，例子很簡單，有兩個類型Order、Product，用來完成一般的業務邏輯處理，我們通過不同的模式來看到底如何使用。
現在的事務腳本模式的代碼：
namespace Business { public class Order { [Serializable] public class OrderField { public string OId { get; set; } [NonSerialized] public List<Product.ProductField> Products { get; set; } } public OrderField Field { get; set; } public void AddOrder(OrderField orderField) { var sendMQOrders = new List<string>();//合格的產品ID集合 orderField.Products.ForEach(product => { if (product.Price <= 20)//不滿足條件 return; sendMQOrders.Add(product.PId);//滿足條件 }); MqHelper.SendOrder(orderField, sendMQOrders);//發送訂單數據實體到隊列中 } } }
Order業務類中有一個添加Order的方法，在該方法中是一些簡單的業務邏輯處理，判斷了要添加的這個商品的價格是否大於20塊錢。最后使用過濾下來的商品ID作為本訂單的有效產品。
這就是我們目前使用的代碼風格，這里有兩個問題，第一：類的命名，Order的概念太大了，沒有進行細化，顯然不是按照事務腳本模式來進行設計的而是按照表模塊方式進行划分的，還有如果我就算你是按照事物腳本模式來設計的，我就喜歡定義大的概念難道不對嗎？也可以，但是在Order的定義里面明確使用了Product類型下的子類型，也就說這里出現了兩個獨立的業務范圍，正常的理解肯定是按照表模塊模式來設計的。第二：如果是按照表模塊模式來設計的，因為根據這個對象的命名很明顯是此模式，但是仔細閱讀一下代碼發現職責還是有點不清晰，在Order.AddOrder(OrderField orderField)方法中，有Product的邏輯在里面if (product.Price <= 20)，當然這里是業務邏輯比較簡單的情況下的，如果是業務比較復雜的時候，就會出現大量的代碼在Order類中，到最后就會發現我們已經分不清此業務架構到底是使用何種模式來設計的。
我們有兩個做法，第一個做法是：將其改成事務腳本模式，讓類的命名和設計泛化，也就是說不要定義那么明顯的數據庫中的表名字，不要清晰的區分Order和Product兩個職責。第二個做法是：將其改成表模塊模式，將每個類型中的業務邏輯完全清晰化，將if (product.Price <= 20)提取到Product業務類中去，然后在應用控制器中先處理此邏輯后在調用Order.AddOrder(OrderField orderField)方法進行處理，這個方法里面只做跟當前類型相關的邏輯，參考的依據就是一旦你發現你所寫的代碼里出現了別的類型時，此時你應該告訴自己有可能這個地方需要重構職責。
兩個方法來移動此邏輯：
1：（將if (product.Price <= 20)封進Price屬性中）
namespace Business { public class Order { [Serializable] public class OrderField { public string OId { get; set; } [NonSerialized] public List<Product.ProductField> Products { get; set; } } public OrderField Field { get; set; } public void AddOrder(OrderField orderField) { var sendMQOrders = new List<string>();//合格的產品ID集合 orderField.Products.ForEach(product => { if (product.Price.IsValid()/*執行價格判斷*/) return; sendMQOrders.Add(product.PId);//滿足條件 }); MqHelper.SendOrder(orderField, sendMQOrders);//發送訂單數據實體到隊列中 } } }
此方法有個問題就是商品的價格沒有收到訂單的控制，這看具體的業務需要了，我只是個假設。
2：完全獨立的過濾無效產品的方法
namespace Business { public class OrderApplicationController { public void SubmitOrder(Order.OrderField field) { field.Products = new Product().FilterProduct(field.Products);//先過濾 new Order().AddOrder(field);//在添加 } } }
我們先調用Product中的業務方法過濾無效的商品，然后在進行訂單添加操作，這樣我們就將各自的職責放到自己的位置去。
4.總結
還是那句話，這只是我學習過程中的一點小小的領悟，給大家一個參考的資料，希望對你有用，謝謝。