企業應用架構模式 之 領域邏輯模式
領域邏輯的組織可以分為三種主要的模式：事務指令碼，領域模型，表模組。
面向過程的開發模式：事務指令碼
事務指令碼是這樣乙個過程開發邏輯：從表示層獲得輸入，進行校驗和計算處理，將資料儲存回資料庫中，以及呼叫其他系統的操作等。然後，該過程將更多的資料返回給表示層，中間可能要進行大量的計算來組織和整理返回值。基本的組織模式就是讓每個過程對應使用者可能做的乙個動作。所以，我們可以將這一模式想象成乙個動作或業務事務的教本。該教本可以拆分為不同的子過程，這些子過程可以在不同的事務指令碼中共享。但是每個動作都由乙個過程來驅動的。
事務指令碼的開發模式是基於過程的，所以它發揮不了物件導向開發語言的優勢，尤其是在領域邏輯複雜性增加時候，缺點就顯的更為明顯。企業應用開發中，往往類似的業務很多，所以相似的動作不可避免，通常會使多個指令碼包含某些相同的**。通過將這些**提取為公共的子過程可以部分的消除這種情況，但在很多時候，消除副本，檢測副本都很困難。這使的應用程式沒有清晰的結構，帶來測試，修改，維護等等的不便。
所以，事務指令碼一般只用在簡單的案例中，但是建議物件導向的開發人員，即使在簡單的案例中也寧願使用領域模型。雖然適應領域模型的思維方式比較困難，但是，一旦習慣了領域模型，從而受益終生。
面向資料集的開發模式：表模組
表模組是處理某一資料庫表或檢視中所有行的業務邏輯的乙個例項。表模組通過強型別或弱型別的資料集與物件結合使用，使用主鍵查詢資料，是.net中使用的很多的一種模式，主要使用主鍵、半物件化的運算元據。之所以說是半結構化，是因為所用的物件基本上只具有行為，通過傳入引數執行特定的操作或者查詢記錄集，而幾乎不承載任何資料。在.net中，這種模式因為其容易和ui進行繫結和互動，所以倍受歡迎。
dotnet以及delphi都提供了大量的資料感知元件，可以使用rad的快速開發模式來開發基於dataset，datatable的企業級應用。這種開發模式其實就是基於表模式的。我們只要在介面上擺放一些資料感知元件比如datagrid等，然後設定同資料來源的連線，以及 連線的表，顯示的字段，乙個簡單的程式就搞定了。
面向資料集的開發模式非常使用於中小型的企業級應用開發，也是國內很多公司的開發模式。但是對於複雜的應用程式來說，業務邏輯的複雜程度會使該種開發方式顯的力不從心。
首先，使用rad和資料感知元件，就使資料顯示層和資料庫表緊耦合，任何對資料模型的改變都會導致所有繫結到改動的表字段的資料感知元件的修改。這就是在delphi開發中，很多開發者寧願使用stringgrid以及listview等資料非感知元件做資料顯示控制項的原因了。
其次，從弱型別資料集中讀取資料時，通常是根據欄位名來獲取欄位的物件的值，比如datatable["name"].tostring(),該方法是以字串為索引來獲得資料集中的字段值，所以如果欄位名稱寫錯了，錯誤也不會在編譯期發現，只有在執行期報錯，這就給排錯帶來困難。
使用資料感知元件，意味著和資料庫的特有特性的緊耦合。比如為了減少**量和提高效率，經常需要使用一些資料庫平台相關的特殊sql，或者將一些複雜的sql寫成平台相關的儲存過程，這樣當向不同資料庫平台移植時，需要重新編寫大量的業務邏輯，這也就是企業級開發中，建議少用甚至不用儲存過程的原因了【注意是企業級應用開發】。而物件導向的開發方式有一般基於物件導向的查詢語言，比如hibernate的hql語言，具有一致性，更加容易實現資料庫平台無關性，實現系統方便地遷移。
基於資料集的開發模式難於應用繼承，多型，設計模式等物件導向的開發方法，而且資料集物件不能包含自定義的操作。而領域模型則沒有這樣的障礙，開發的系統更加直觀，更加容易維護。
物件導向的開發模式：領域模型
在最壞的情況下，業務邏輯可能會變的極其複雜。此時，規則和邏輯描述了許多不同的用例和行為的變化。物件正是針對這種複雜性而設計的，物件導向的特性加上設計模式足以應對複雜的業務邏輯。
企業級應用的資訊載體是各種資料庫，而資料庫表是基於關係的，假如能夠把關係資料表轉化為物件，使得運算元據表如同操作物件一樣靈活，消除對面向資料集的sql的依賴，也就可以應對複雜的企業業務，該有多好啊！
這也就是物件導向的開發模式：領域模型。領域模型建立了一張由物件組成的業務網。其中的每乙個物件都代表某個有意義的個體，可能大到乙個公司也可能小到訂單的一行。
物件導向的領域模型通常和面向關係的資料庫模型類似，但仍然有許多不同。領域模型混和資料和處理過程，擁有賦值屬性和複雜的關聯，並且可以使用繼承。
所以，領域模型衍生了兩種風格：簡單領域模型和複雜領域模型。
簡單領域模型可以使用活動記錄，即簡單的單條資料記錄和單個物件對應的模式，乙個物件對應資料庫中的乙個表。
複雜領域模型需要使用資料對映器，它可能使用繼承、策略或者其他的設計模式，是一張由互聯的細粒度物件組成的複雜網路，我們經常會看到：多個類通過互動來完成很簡單的任務。複雜領域模型更適用於複雜的邏輯，但它到資料庫的對映比較困難。
領域模型的要點在於隱藏資料庫的存在，轉化業務操作為物件操作。
orm[物件關係對映]是現在流行的解決資料庫轉化為物件的思想，而hibernate框架是其中的佼佼者。
【注：活動記錄和資料對映器都是企業應用架構模式。】
讀《企業應用架構模式》4 關於組織領域邏輯
關於領域邏輯的組織主要講了 貫穿領域層裡的某些東西 1.事務指令碼 指令碼 顧名思義就是 sql語句 當然如果我們運算元據庫，必然要在乙個事務中，這樣就出會事務指令碼的概念，估計市場是小的應用都是這樣的組織的，記得8年前做廣電專案的時候，就是這用他來組織 的，如果大家看過bbs 大部分也是應用這種模...
企業應用架構模式之物件 關係結構模式
前面已經介紹了物件 關係行為模式，包括工作單元 標識對映 延遲載入，這些都是協調記憶體物件與關聯式資料庫之間行為操作的一些方法。記憶體物件與關聯式資料庫除了行為需要協調之外，在結構上也需要一些方法來保證彼此的完整，這就是物件 關係結構模式。這些方法主要有 標識域 外來鍵對映 關聯表對映 依賴對映 嵌...
企業應用架構模式之Web表現模式
1 mvc 把使用者介面互動分拆到不同的三種角色模型 檢視 與控制器上。模型表示領域資訊物件 檢視表示ui中模型的顯示 控制器獲得使用者輸入，對模型進行操作並更新檢視。mvc關注兩個分離 從模型中分離表現和從檢視中分離控制器。2 頁面控制器 在web 站點上為特定頁面或者動作處理請求的物件。頁面控制...