測試SQL Server業務規則連結方法

iSQlServer發表於2009-08-03

有一個持續很長時間的爭論,是關於在哪裡儲存應用程式業務邏輯的:是在應用程式本身的業務邏輯層中還是在資料庫層中。應用程式邏輯層的絕對支持者提出,資料庫的唯一目的就是儲存資料,以備應用程式所用。提倡用資料庫來儲存業務規則的人則堅持認為,業務規則最好儲存在資料庫中,因為資料也儲存在那裡,規則在那裡更容易執行。而在我看來,對於儲存應用程式的邏輯來說,沒有一個“最好的地方”——它真正取決於您正在解決的業務問題。

連結資料庫儲存過程

如果您更喜歡將全部或一部分業務邏輯儲存在資料庫中的話,那麼知道 SQL Server 中的一種被我稱作業務規則連結的技術是很有好處的。基本思想就是您可以在資料庫中執行一系列的儲存過程,這是以在您需要的時候,不同程式的後設資料儲存在一個資料庫表格中為基礎的。這樣做的好處就是,規則都儲存在資料庫的程式中,並且因為儲存過程的執行是以一個表格中的值為基礎的,所以您可以改變程式執行的順序,還能夠很容易地開啟或終止業務規則。讓我們來看一個例子,這樣概念會更清晰。

業務規則連結例項

要用我想用的方式在資料庫中執行業務規則,就必須定義後設資料。下面這些資訊將會以資料庫表格的形式被儲存:儲存過程的名稱、業務規則執行的順序、所執行業務程式的型別和業務規則是否活動等。列表A中包括了建立表格的指令碼。

CREATE TABLE BusinessLogic
(
 ProcessType VARCHAR(20) NOT NULL,
 RunSequence TINYINT NOT NULL,
 LogicProcedure VARCHAR(255) NOT NULL,
 BusinessLogicActive BIT DEFAULT(1) NOT NULL,
 CONSTRAINT pk_BusinessLogic PRIMARY KEY (ProcessType, RunSequence)
)

在列表 B 中,我在 BusinessLogic 表中載入了資料。這些資料是稍後我將用來處理業務規則的。RunSequence 是執行儲存過程的實際順序(過程被儲存在 LogicProcedure 欄位中)。表格中還包含了一個指示符,用來表示業務規則是否為活動的。儲存這個資料讓我能夠改變規則執行的順序,或者在需要的時候開啟或終止規則,而無需對程式碼做出更改。要向業務邏輯系統中新增規則也十分簡單,因為所需做的就是向資料庫中新增程式,然後在後設資料表格中新增需要的資料就可以了。

INSERT INTO BusinessLogic(ProcessType, RunSequence, LogicProcedure)
VALUES('CustomerOrders', 1, 'usp_Rule1')
INSERT INTO BusinessLogic(ProcessType, RunSequence, LogicProcedure)
VALUES('CustomerOrders', 2, 'usp_Rule2')
INSERT INTO BusinessLogic(ProcessType, RunSequence, LogicProcedure)
VALUES('CustomerOrders', 3, 'usp_Rule3')
INSERT INTO BusinessLogic(ProcessType, RunSequence, LogicProcedure)
VALUES('CustomerOrders', 4, 'usp_Rule4')

在列表 C 中,我建立了業務規則程式(例子中包含的程式是非常簡單的;但是,在現實情況中,如果需要的話,它們可以很複雜)。所有的程式中包括了相同的輸入引數;這是業務規則連結的一個小小的侷限性。

CREATE PROCEDURE usp_Rule1 (@RunSequence TINYINT)
AS
 PRINT 'In Procedure: ' + OBJECT_NAME(@@PROCID)
 PRINT 'Parameter Value Passed In:' + CAST(@RunSequenceAS VARCHAR(2))
GO
CREATE PROCEDURE usp_Rule2 (@RunSequence TINYINT)
AS
 PRINT 'In Procedure: ' + OBJECT_NAME(@@PROCID)
 PRINT 'Parameter Value Passed In:' + CAST(@RunSequenceAS VARCHAR(2))
GO
CREATE PROCEDURE usp_Rule3 (@RunSequence TINYINT)
AS
 PRINT 'In Procedure: ' + OBJECT_NAME(@@PROCID)
 PRINT 'Parameter Value Passed In:' + CAST(@RunSequenceAS VARCHAR(2))
GO
CREATE PROCEDURE usp_Rule4 (@RunSequence TINYINT)
AS
 PRINT 'In Procedure: ' + OBJECT_NAME(@@PROCID)
 PRINT 'Parameter Value Passed In:' + CAST(@RunSequenceAS VARCHAR(2))
GO

接下來就是處理業務規則的程式碼了。在列表 D 中,我用一個指標在表格中迭代,該表格中的記錄都儲存著後設資料。當可以用一種不同的迴圈結構來完成同一個邏輯時,用指標要簡單一些。不管是怎麼樣完成的,都需要用某種型別的迭代迴圈和執行所需要的業務程式。執行這個程式碼將執行每一個文章前面所定義的四個儲存過程。

在列表 D 中,有兩個主要引人注意的地方。第一個就是用來從表格中檢索記錄的 select 語句,所檢索的記錄中包含了處理業務規則的資訊。從這個簡單的查詢中,我可以為任何型別的業務處理從 BusinessLogic 表中返回行。我還能保證規則是活動的,並且按照它們需要執行的順序返回。

DECLARE @LogicProcedure VARCHAR(255)
DECLARE @RunSequence TINYINT
DECLARE LogicCursor CURSOR
FOR
SELECT LogicProcedure, RunSequence FROM BusinessLogic
WHERE
 ProcessType = 'CustomerOrders' AND
 BusinessLogicActive = 1
ORDER BY RunSequence ASC
OPEN LogicCursor
FETCH NEXT FROM LogicCursor
INTO @LogicProcedure, @RunSequence
WHILE @@FETCH_STATUS = 0
BEGIN
 EXECUTE @LogicProcedure --//Call procedure stored in variable
 @RunSequence = @RunSequence --//Pass in parameter
 PRINT '-----------------------------'
FETCH NEXT FROM LogicCursor
INTO @LogicProcedure, @RunSequence
END
CLOSE LogicCursor
DEALLOCATE LogicCursor
GO

第二個就是執行業務規則的方式。當指標迭代時,它從 BusinessLogic 表中檢索將要被執行的儲存過程的名稱,然後將其儲存在一個邏輯變數中。EXECUTE 命令允許使用者執行儲存過程,即使該儲存過程的名稱被儲存在一個變數中。在這種方式下,呼叫儲存過程還使得我能夠向儲存過程中輸入所需的引數。

這使我回到了先前關於業務程式具有相同數量的輸入引數這一點。我能夠以一種相當動態的方式執行業務程式,這取決於在程式執行時 BusinessLogic 表中儲存了什麼。但是,現在我還沒有一種方法可以動態地向業務程式輸入引數。

一種簡單的解決辦法就是保證所有的業務程式接受相同數量的引數,不管用不用它們。這種技術保證我們始終為業務程式提供所需的引數。也有其他的方法可以實現這些所需引數的輸入,但是那些不是這篇文章所要討論的。

扼要重述

如果您的應用程式在資料庫中儲存它的任何一個或全部業務邏輯,那麼有可能它就是被我稱作業務規則連結的一個候選者。這種方法允許儲存過程在資料庫中依次執行,並且讓您能夠在需要的時候開啟或終止這些業務規則。

檢視原文地址:http://database.違規廣告.com/art/200902/109738.htm

來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/16436858/viewspace-611150/,如需轉載,請註明出處,否則將追究法律責任。

相關文章