测试SQLServer业务规矩链接方法

有一个古老的争辩，是关于在哪里存储利用程序业务逻辑的：是在利用程序本身的业务逻辑层中还是在数据库层中。利用程序逻辑层的尽对支撑者提出，数据库的唯一目标就是保留数据，以备利用程序所用。提倡用数据库来存储业务规矩的人则保持认为，业务规矩最好存储在数据库中，由于数据也存储在那里，规矩在那里更轻易运行。而在我看来，对于存储利用程序的逻辑来说，没有一个“最好的处所”——它真正取决于您正在解决的业务标题。

链接数据库存储过程

假如您更爱好将全部或一部分业务逻辑存储在数据库中的话，那么知道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的认证。