Domain logic approachs

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

1.transaction script(事務腳本)數據庫

概述:數據結構

不少企業應用能夠當作一系列的事務,每個事務能夠經過使用一個Transaction Script來處理。app

用法:dom

 使用Transaction Script,咱們能夠專一於處理好每個事務,而沒必要考慮其餘事務的影響,所做的就是獲得輸入,查詢數據庫,處理事務,保存結果。        Transaction Script能夠有兩種方法組織成類。一種是將同一領域的幾個Transaction Script放在一個獨立的類中;另外一種是採用Command模式,將每個Transaction Script組織成一個Command基類的子類;固然,也能夠不要組織成類,而使用全局函數的方式,可是類的方式更易於隔離數據。函數

適用狀況:性能

Transaction Script最大的優勢和缺點,都是在於它的簡單性。優勢是代碼的簡單易懂,運行效率也不錯;缺點是極可能出現代碼重複,固然這個能夠經過重構來減輕,更重要的是,隨着企業事務複雜性的增長,Transaction Script就會變得力不從心。        Transaction Script下的開發有如下特徵:對象類只包括數據,不包括任何事務相關的算法,每每就是數據庫中表結構的類化;調用的Sql語句經常在Transaction Script核心函數中出現,固然這個是很差的設計,應該使用好比Table Data GateWay等模式,將Sql語句封裝在wrapper中,來進行數據庫交互,而核心函數直接訪問wrapper的方法來進行事務處理。設計

 事務腳本組織成類的方法:對象

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

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

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

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

2.domain model(域模型)

概述:

域模型是抽象系統,描述知識,影響或活動領域的選定方面(域)。而後,該模型可用於解決與該域相關的問題。域模型表示與須要在軟件中建模的域相關的有意義的現實世界概念。這些概念包括業務中涉及的數據以及業務與該數據相關的規則。

域模型一般使用域的詞彙表,從而容許將模型的表示傳達給非技術利益相關者。它不該該指任何技術實現,例如正在設計的數據庫或軟件組件。

用法:

域模型一般被實現爲層內的對象模型,該層使用較低層的層來持久化而且將API「發佈」到更高層的層以得到對模型的數據和行爲的訪問。

在統一建模語言(UML)中,類圖用於表示域模型。

 

3.table module(表模塊)

概述:

Table Module是處理一個數據表或者數據視圖全部行的業務邏輯的一個單獨的實例。    通常的,Domain Model等傳統面向對象模式都創建在對象/身份的基礎之上,就是說好比一個員工類的實例就對應着一個特定的員工,這樣咱們能夠執行員工操做,獲取員工信息等。這些模式的很差之處在於很難和關係數據庫造成好的接口,致使咱們要做大量工做用於處理數據在業務層和數據庫這兩個表現徹底不一樣的層次之間的傳遞。    Table Module則否則,它對於數據庫中的每一個表創建一個類的實例,用來操做該表中的數據。

用法:

Table Module模式使得咱們能夠打包數據和它們的行爲,並同數據庫保持很好的聯繫。它經常做爲面向表的後臺數據結構,而表狀的數據通常的是Sql語句調用的RecordSet返回值。    Table Module便可以使類的單獨實例,也能夠是類的一組靜態函數。採用實例的方式給咱們更大的好處,便於經過一個存在的RecordSet來初始化,也很容易的經過繼承等方式進行擴展。    Table Module模式能夠經過廠模式來實現請求,另外的方法是經過Table Data Gateway,很差的是引入了Table Data Gateway類和機制,好的方面是咱們能夠只使用一個Table Module了,對於不一樣的數據源,採用不一樣的Table Data Gateway就能夠了    Table Module使用方法是:首先經過Table Data Gateway把數據裝成RecordSet,而後以其爲參數建立Table Module,經過Table Module來處理業務邏輯,並把修改的結果傳回數據庫。中間的過程當中,RecordSet數據一直在內存中,而沒必要返回數據庫。    固然Table Module並不侷限於表,表/視圖/Sql查詢結果等均可以應用此模式

適用狀況:

Table Module基於面向表的數據,並且它必定是把數據結構放在整個代碼的中心。面對一個複雜的業務邏輯,它不能提供足夠的實例-to-實例的能力,在處理多態上也存在不足,這時咱們仍是應該採用Domain Model,Domain Model+Active Record也能夠處理表狀的數據。    Table Module在COM應用中比較常見,這是由於微軟的ADO庫提供了一個很好的機制,使用RecordSet來處理數據庫的數據。

相關文章
相關標籤/搜索