事務指令碼模式可能是最簡單的業務邏輯模式，它完全是過程式的。
事務指令碼是乙個方法——使用者通過表現層的操作傳送的請求進而形成的方法。
事務——通常指執行的業務
指令碼——指一組系統執行的操作(也就是指令碼)與每個使用者操作在邏輯上關聯起來。
ts建議跳過任何物件導向設計，把業務元件直接對映到所需的使用者操作上。
在ts裡，每個所需的使用者操作的實現都是在物理事務的邊界裡從開始執行到結束。資料訪問通常封裝到一組元件裡，元件通常會放入資料訪問層。按照模式，ts沒有包含任何物件導向設計的成分。通過ts建模的任何邏輯都是通過if、while和for等語言語法元素表達。
注意：通過ts實現業務邏輯的系統有乙個比較緊湊的分層架構，在這個架構裡，ts與應用程式層重合，直接連線資料訪問層。最終的架構與經典的三層架構一樣。下圖(事務指令碼模式的鳥瞰圖)概述了事務指令碼模式的精髓
ts己經用了很多年，但不會那麼快被淘汰只有乙個原因：它推動從任務的角度看待業務邏輯，正如你在過去的章節裡看到的，這正是提高使用者體驗的關鍵。
ts適合業務邏輯簡單，最好是不大可能改變和發展的簡單場景。
通常，ts適合任何不打算使用領域建模的場景，不管何種原因，不管是複雜性有限還是技能有限。
重要：從資料庫快速推斷的指令碼物件模型，雖然仍可能被稱為領域模型，但它其實是貧血領域模型。如在簡單的crud系統中，且缺乏領域建模相應的知識時候，可以使用ts。其中，通過把系統分成命令和查詢兩部分，使用ts實現命令部分非常容易，可以把更多時間和精力用於為系統的查詢部分設計乙個有效的模型。
注意：簡單和複雜都是不容易衡量的概念。更重要的是，什麼是簡單以及什麼是複雜取決於個人的態度和技能。如果你做了很多年物件導向設計，也對你的東西很了解，那麼設計乙個簡單的領域模型比起切換回去過程式編碼對於你來說可能更簡單、更快速。因此，沒有必要每次覺得複雜性低於乙個普遍認同的臨界值時就選擇ts。就實現而言，可以在乙個類裡為每個事務指令碼建立乙個單獨方法，它可能是靜態的，也可以為每個事務指令碼建立它自己的類。這樣做的話，最終會得到命令(command)模式的乙個很好的實現。更簡單地說，一旦你覺得你這個系統有了全面的認識，並且這個系統就需求和業務規則而言並沒有太過複雜，你就應該認真考慮一下ts。物件使得**優雅，但只有在**可以工作並且正確工作的時候這種優雅才有意義。使用ts並沒有什麼好羞恥的，尤其在適合使用ts的情況下。
銜接命令模式
命令模式是其中乙個最常用的行為設計模式，它使用物件來表示操作。命令物件封裝了乙個操作及其所有引數。通常，命令物件暴露乙個標準介面，以便呼叫方可以在不深入了解實際執行任務的命令類的情況下呼叫任何命令。下面是乙個簡單的例子：
public
inte***ce
public
class
bookhotelroom
public string confirmationnumber
}public
intrun()
}
業務邏輯層之事務指令碼與領域模型
在前面的部落格中，已了解了前端控制器，頁面控制器，應用控制器這三種表現層模式，如果說它們精心安排了外部世界與系統內部的通訊，那麼業務邏輯層的工作則是處理應用程式的業務部分。業務邏輯層應當遠離那些外部的 噪音 業務邏輯是整個應用程式的根本目的所在，系統的其它部分都是為這部分服務的。這裡介紹兩種經常使用...
設計模式 業務代表模式
業務代表模式 business delegate pattern 用於對表示層和業務層解耦。它基本上是用來減少通訊或對表示層 中的業務層 的遠端查詢功能。在業務層中我們有以下實體。我們將建立 client businessdelegate businessservice lookupservice ...
簡單設計模式實現業務邏輯與流程邏輯的分離
在企業應用系統開發中，特別是涉及到多部門協同作業的情況，業務流程是最難確定下來的，應用系統開發過程中和應用系統上線後流程經常會發生變化。如何採用有效，合理成本的方式來處理這種現象呢？如果做到在應用系統開發中業務邏輯與流程邏輯分離，即可達到業務流程不確定的情況下的不影響開發進度，同時有可以提公升應用系...