测试SQL Server业务规则链接方法

　　有一个持续很长时间的争论，是关于在哪里存储应用程序业务逻辑的：是在应用程序本身的业务逻辑层中还是在数据库层中  。应用程序逻辑层的绝对支持者提出，数据库的唯一目的就是保存数据，以备应用程序所用  。提倡用数据库来存储业务规则的人则坚持认为，业务规则最好存储在数据库中，因为数据也存储在那里，规则在那里更容易运行  。而在我看来，对于存储应用程序的逻辑来说，没有一个“最好的地方”——它真正取决于您正在解决的业务问题  。

　　链接数据库存储过程

　　如果您更喜欢将全部或一部分业务逻辑存储在数据库中的话，那么知道 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 表中储存了什么  。但是，现在我还没有一种方法可以动态地向业务程序输入参数  。

　　一种简单的解决办法就是保证所有的业务程序接受相同数量的参数，不管用不用它们  。这种技术保证我们始终为业务程序提供所需的参数  。也有其他的方法可以实现这些所需参数的输入，但是那些不是这篇文章所要讨论的  。

　　扼要重述

　　如果您的应用程序在数据库中储存它的任何一个或全部业务逻辑，那么有可能它就是被我称作业务规则链接的一个候选者  。这种方法允许存储过程在数据库中依次运行，并且让您能够在需要的时候打开或终止这些业务规则  。