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

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

链接数据库存储过程

假如您更喜欢将全部或一部分业务逻辑存储在数据库中的话，那么知道SQL Server中的一种被我称作业务规则链接的技术是很有好处的。基本思想就是您能够在数据库中运行一系列的存储过程，这是以在您需要的时候，不同进程的元数据存储在一个数据库表格中为基础的。这样做的好处就是，规则都存储在数据库的程式中，并且因为存储过程的运行是以一个表格中的值为基础的，所以您能够改变程式执行的顺序，还能够很容易地打开或终止业务规则。让我们来看一个例子，这样概念会更清楚。

业务规则链接实例

要用我想用的方式在数据库中执行业务规则，就必须定义元数据。下面这些信息将会以数据库表格的形式被保存：存储过程的名称、业务规则运行的顺序、所运行业务程式的类型和业务规则是否活动等。列表A中包括了创建表格的脚本。

在列表B中，我在BusinessLogic表中加载了数据。这些数据是稍后我将用来处理业务规则的。RunSequence是执行存储过程的实际顺序（过程被存储在LogicProcedure字段中）。表格中还包含了一个指示符，用来表示业务规则是否为活动的。存储这个数据让我能够改变规则运行的顺序，或在需要的时候打开或终止规则，而无需对代码做出更改。要向业务逻辑系统中添加规则也十分简单，因为所需做的就是向数据库中添加程式，然后在元数据表格中添加需要的数据就能够了。

在列表C中，我创建了业务规则程式（例子中包含的程式是很简单的；但是，在现实情况中，假如需要的话，他们能够很复杂）。任何的程式中包括了相同的输入参数；这是业务规则链接的一个小小的局限性。

接下来就是处理业务规则的代码了。在列表D中，我用一个指针在表格中迭代，该表格中的记录都保存着元数据。当能够用一种不同的循环结构来完成同一个逻辑时，用指针要简单一些。不管是怎么样完成的，都需要用某种类型的迭代循环和执行所需要的业务程式。运行这个代码将执行每一个文章前面所定义的四个存储过程。

在列表D中，有两个主要引人注意的地方。第一个就是用来从表格中检索记录的select语句，所检索的记录中包含了处理业务规则的信息。从这个简单的查询中，我能够为任何类型的业务处理从BusinessLogic表中返回行。我还能确保规则是活动的，并且按照他们需要执行的顺序返回。

第二个就是执行业务规则的方式。当指针迭代时，他从BusinessLogic表中检索将要被执行的存储过程的名称，然后将其储存在一个逻辑变量中。EXECUTE命令允许用户执行存储过程，即使该存储过程的名称被储存在一个变量中。在这种方式下，调用存储过程还使得我能够向存储过程中输入所需的参数。

这使我回到了先前关于业务程式具备相同数量的输入参数这一点。我能够以一种相当动态的方式运行业务程式，这取决于在程式运行时BusinessLogic表中储存了什么。但是，现在我还没有一种方法能够动态地向业务程式输入参数。

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

扼要重述

假如您的应用程式在数据库中储存他的任何一个或全部业务逻辑，那么有可能他就是被我称作业务规则链接的一个候选者。这种方法允许存储过程在数据库中依次运行，并且让您能够在需要的时候打开或终止这些业务规则。使用这种方法的一些潜在缺陷包括数据安全（执行业务程式的数据储存在一个表格中），和向业务逻辑程式输入参数的非动态性。假如您觉得对于您的业务问题来说，这种方法利大于弊的话，我鼓励您尝试一下这种方法。

Tim Chapman是肯塔基州路易维尔市一家银行的SQL Server数据库管理员，他有超过7年的行业经验。他还通过了微软SQL Server 2000和SQL Server 2005的认证。

标签：

版权申明：本站文章部分自网络，如有侵权，请联系：west999com@outlook.com
特别注意：本站所有转载文章言论不代表本站观点，本站所提供的摄影照片，插画，设计作品，如需使用，请与原作者联系，版权归原作者所有