業務邏輯層之事務指令碼與領域模型

2021-07-05 08:36:37 字數 2615 閱讀 8796

在前面的部落格中,已了解了前端控制器,頁面控制器,應用控制器這三種表現層模式,如果說它們精心安排了外部世界與系統內部的通訊,那麼業務邏輯層的工作則是處理應用程式的業務部分。業務邏輯層應當遠離那些外部的「噪音」。業務邏輯是整個應用程式的根本目的所在,系統的其它部分都是為這部分服務的。

這裡介紹兩種經常使用的領域邏輯模式:事務指令碼模式和領域模型模式。

一、事務指令碼

1.1 概念

transaction script:使用過程來組織業務邏輯,每個過程處理來自表現層的單個請求。貌似有點太抽象了。大多數業務應用都可以被看作是一系列事務,有時候,事務可能就顯示下資料庫的資訊,有時候,也可能涉及許多校驗和計算的步驟。事務指令碼則將所有這些邏輯組織成單個過程,而且每個事務都有自己的事務指令碼,就是都有自己的執行過程,但注意的是事務間的公共子任務可以被分解成多個子程式。

1.2 為什麼要使用事務指令碼

事務指令碼模式的好處在於你可以很快就得到想要的結果。每個指令碼都能很好地處理輸入的資料並運算元據庫來保證得到想要的結果。因此它是乙個快速而有效的機制,且不需要投入大量時間和精力在複雜的設計上,對於小型且工期較緊的專案再適合不過。

1.3 實現事務指令碼

具我工作經驗觀察,許多程式設計師都渾然不知地在使用這種模式,包括本人以前。

現在假設有發表部落格和刪除部落格的業務,那將這兩個業務分別看成兩個事務指令碼。

php**  

<?php   

//這裡建立乙個基類,作資料處理,假設用的是pdo

abstract

class base   

self::$db = new \pdo( $dsn );  

self::$db->setattribute(\pdo::attr_errmode, \pdo::errmode_exception);  

}   

protected

function dostatement()   

}  class blogmanager extends base   

//刪除部落格事務指令碼

function delblog(...)    

}  ?>  

這個例子十分簡單,但正因為它的簡單,才正好體現了事務指令碼的優勢之處。如果寫乙個較為複雜應用程式,這種方式使專案不太容易擴充套件,因為事務指令碼總是不可避免地互相滲入,從而導致**重複。

二、領域模型

2.1 概念

domain model:很難用語言說清楚。簡單的說就是領域模型象徵著真實世界裡專案中的各個參與者。「萬物皆物件」的原則在此體現得淋漓盡致。在其他地方物件總是帶著種種具體的責任,而在領域模式中,它們常常描述為一組屬性及附加的**。它們是做某些事的某些東西。

2.2 為什麼要使用領域模型

現實**中,會有很多事務指令碼模式的身影,會發現重複**是個普遍問題。當不同的事務要執行相同的任務時,重複貌似是最快的解決辦法,但這大大增加了**維護的成本。有時也可以通過重構來解決,但慢慢地複製貼上可能成了開發中難以避免的一部分。

2.3 實現領域模型

為實現對比,引用事務模型的例子,並將領域模型類直接對映到關聯式資料庫的表(這樣做會使得開發變得簡單)

php**  

<?php   

//這裡建立乙個基類,作資料處理,假設用的是pdo

abstract

class base   

self::$db = new \pdo( $dsn );  

self::$db->setattribute(\pdo::attr_errmode, \pdo::errmode_exception);  

}   

protected

function dostatement()   

}  class blogmodel extends base  

}  //建立乙個領域模型的基類

abstract

class domainobject   

function getid( )   

//牢記 萬物皆物件

static

function getcollection( $type )   

}  class blog extends domainobject   

function addblog(...)  

function setfeed( feedcollection $feed )   

}  ?>  

2.4 小結

領域模型設計得簡單還是複雜取決於業務邏輯的複雜度。使用領域模型的好處是:當你設計模型時可以專注於系統要解決的問題,而其他的問題(如持久化和表現等)可以由其他層來解決。

在實現專案中,大多數程式設計師在設計領域模型時還是把一半的注意力都放在資料庫上。將領域模型和資料層分離會導致一定的代價,你也可能會將資料庫**直接放入模型中(儘管你可能會使用乙個資料入口來處理實際的sql)。對於相對簡單的模型,特別當類與資料表一一對應時,這樣方法是完全可行的,可以減少因協調物件和資料庫而建立外部系統導致的時候消耗。

領域模型 And 事務指令碼

事務指令碼和領域模型之間的區別還是很明顯的,顯然,我們常見的系統中沒有太多是採用領域建模來實現的 而大部分是採用事務指令碼來實現。我承認事務指令碼在解決簡單問題方面確實是簡單,特別是只是簡單的crud問題。事務指令碼的乙個最重要的特徵是 1.簡單的過程模型。也就是乙個service方法就對應著使用者...

事務指令碼和領域模型

事務指令碼 事務指令碼的核心是過程,通過過程的呼叫來組織業務邏輯,每個過程處理來自表現層的單個請求。大部分業務應用都可以被看成一系列事務,從某種程度上來說,通過事務指令碼處理業務,就像執行一條條sql語句來實現資料庫資訊的處理。事務指令碼把業務邏輯組織成單個過程,在過程中直接呼叫資料庫,業務邏輯在服...

業務邏輯模式 事務指令碼模式

事務指令碼模式可能是最簡單的業務邏輯模式,它完全是過程式的。事務指令碼是乙個方法 使用者通過表現層的操作傳送的請求進而形成的方法。事務 通常指執行的業務 指令碼 指一組系統執行的操作 也就是指令碼 與每個使用者操作在邏輯上關聯起來。ts建議跳過任何物件導向設計,把業務元件直接對映到所需的使用者操作上...