領域邏輯組織

　　

領域邏輯組織能夠分爲三種主要的模式：事務腳本(Transaction Script)、領域模型(Domain Model)和表模塊(Table Module)」

　　事務腳本 Transaction Script

　　使用過程來組織業務邏輯，每一個過程處理來自表現層的單個請求。大多數應用均可以被看做是一系列事務。一個事務可能將某種信息看做是以特定方式組織的，而後另外一事務則會改變它。在客戶系統和服務器系統這間的每次交互都包含必定數量的邏輯。它可能如顯示數據庫中的信息那般簡單。蛤在其餘一些狀況下，它可能涉及許多校驗和計算的步驟。事務腳本將全部這些邏輯組成成單個過程，在過程當中直接調用數據庫，或者只經過一個簡單的數據庫封裝器。每一個事務都有本身的事務腳本，儘管事務間的公共子任務能夠被分解成多個子程序。

　　事務腳本組織成類的方法

　　將數個事務腳本放在一個類中，每一個類圍繞一個主題將相關的事務腳本組織在一塊兒。(最經常使用)

　　每個事務腳本對應一個類，此時需使用命令(Command)模式。使用時機

　　事務腳本勝在簡單。對於只有少許邏輯的應用程序來講，使用這一模式很是天然，不管在性能上仍是理解上都不會帶來太大開銷。

　　當業務邏輯愈來愈複雜時，該模式就會愈來愈難以保持良好的設計。它特有的問題是事務之間的冗餘代碼。

　　領域模型 Domain Model)

　　合併了行爲和數據的領域的對象模型。在應用程序中使用領域模型須要創建一個完整的由對象組成的層，來對目標業務領域建模。 你會發現其中有的對象模擬業務活動中的數據，有的對象捕捉業務使用的規則。數據和處理通常整合在一塊兒，從而使得數據和數據之上的操做緊密聚合。

　　面向對象的領域模型一般看起來與數據庫模型相似，但仍有許多不一樣之處。領域模型混合數據和處理過程，擁有多值和複雜的的關聯網，而且使用繼承。

　　領域模型衍生出兩種風格。簡單領域模型看起來與數據庫設計很相似，這種設計中幾乎每個數據庫表都與一個領域對象對應。而複雜領域模型則與數據庫 設計不一樣，它使用繼承、策略和其餘設計模式，是一張由互聯的細粒度對象組成的複雜網絡，複雜的領域模型更適合於複雜的邏輯，但它於數據庫的映射比較 困難。

　　因爲業務行爲是常常變化的。所以易於修改、建造和測試對領域層來講十分重要。於是，領域模型與系統中的其餘層之間的耦合度應達到最小。許多的分層 模式，它們的主導思想就是領域模型與系統中其餘部分間保持儘量小的依賴

　　使用時機

　　什麼時候使用這一模型徹底取決於系統中的行爲複雜程度。若是你的業務規則複雜多變，涉及檢驗、計算、衍生，你就應該利用對象模型進行處理， 反之，若是你只有一些簡單的判空值和少許的求和計算，事務腳本是一個更佳的選擇。

　　影響選擇的因素之一是開發小組靈活運用領域對象的程度。學會如何使用領域模型是極爲重要的，故而出現了許多」理論體系遷移?方面的文章，它們都是關於 對象使用的。要熟悉領域模型須要實踐和訓練，可是一旦掌握了它，我發現處理解決最簡單的問題外，不多會有人再使用事務腳本。

　　使用領域模型時，你可能會考慮設立一個服務層，以便給領域模型一個更清晰的API。

　　表模塊 Table Module

　　表模塊以一個類對應數據庫中的一個表來組織領域邏輯，並且使用單一的類實例來包含將對數據進行的程序種操做程序。

　　使用時機

　　最常使用這一模式的場合是在Microsoft的COM設計方案中。在COM(及.net)中，記錄集是應用程序的主要數據倉庫。ADO 庫提供了良好的機制，可供你以記錄集的方式來 存取關係數據庫中的數據。

　　如需採納請聯繫博主.qq23728後面本身想法。