4.1  理解業(yè)務組織模式

并非所有應用程序都是一樣的，也并非所有應用程序都需要復雜的體系結構來封裝系統(tǒng)的業(yè)務邏輯。作為開發(fā)者，重要的是要理解所有領域邏輯模式的優(yōu)缺點，這樣才能使用最合適的模式。

4.1.1  Transaction Script

在本章要學習的4種領域邏輯模式中，Transaction Script是最易于理解、掌握和運用的模式。Transaction Script模式遵循的是過程式開發(fā)風格而不是面向?qū)ο蠓椒?。通常，為每個業(yè)務事務創(chuàng)建一個單獨的方法，并將它們組合起來放入某種靜態(tài)管理程序或服務類。每個過程都包含了完成業(yè)務事務所需的所有業(yè)務邏輯，包括工作流、業(yè)務規(guī)則和數(shù)據(jù)庫持久化驗證檢查。圖4-1（圖略）所示為Transaction Script模式的圖形表示。

Transaction Script模式的一個優(yōu)勢是它易于理解，很快就可以讓團隊新成員上手而不需要具有該模式的預備知識。當出現(xiàn)新需求時，很容易向該類中添加更多方法，而不用擔心影響或破壞現(xiàn)有功能。

Transaction Script模式非常適于那些邏輯中只包含很少或不包含可能增長的功能集合的小型應用程序，以及有不熟悉面向?qū)ο缶幊谈拍畹某跫夐_發(fā)者的團隊。

當應用程序變大而且業(yè)務邏輯變得更復雜時，Transaction Script模式的問題就會暴露出來。擴展應用程序時，方法的數(shù)目也會變多，從而形成一個充斥著功能交疊的細粒度方法的無用API。盡管可以使用子方法來避免代碼重復，如驗證和業(yè)務規(guī)則，但在工作流中的復制不可避免，而且當應用程序規(guī)模變大時，代碼基很快會變得笨重且不可維護。

因為Transaction Script模式非常簡單，所以無需一個練習來完整地演示它。相反，考慮下面的代碼段，它取自于一個人力資源休假登記應用程序，有助于了解一下該模式的實際用法：