终于和CLR成了一家人
CLR的集成
通过集成CLR，SQL Server 2005已经获得了很多新的特性，借助CLR的集成可以用任何.NET语言建立存储过程、触发器、用户自定义函数、用户自定义类型、用户自定义聚合。通过这个集成笔者认为SQL Server主要可以获得如下优势。
提供了一个更加完善的开发模型，对于熟悉面向对象的开发人员和一直在SQL Server平台进行T-SQL开发的开发人员都提供开发的舞台。更深层次讲，这两类开发人员可以根据自己熟悉的领域对应用进行优化，T-SQL开发人员可以根据执行计划分析和优化应用，面向对象开发人员可以根据已有的Best Practice，借助代码复查以优化自己的应用。
提供了更好的安全性，这个主要来源于CLR运行于托管环境的原因，通过运行过程中CAS（Code-Access Security），所有的代码执行过程都是在一个安全的调用链运行，与以往不同的是，即便用户获得了某个已开发好的功能的使用权限，但是如果该功能所使用的某个组件的安全性与目标资源的安全性相冲突，也会被CLR判断为非法。
以往的代码面临的主要安全问题如下：
1. 非授权使用或者越权使用；
2. 代码注入；
3. 额外信息泄漏；
4. 伪装、欺骗代码执行；
图1：执行过程中代码主要面临的安全问题
那么在CLR中，执行每一个Assembly的时候都要基于既有的或者定制的安全策略进行访问检查，不仅仅是调用者权限检查，也包括用户与目标资源之间的访问关系，更为主要的是在每个功能调用的过程中，还要检查每上游组件的安全要求是否与自身安全要求抵触，如果出现异常，那么这个调用链也会被终止。执行过程如下：
图2：单个Assembly的执行过程
图3：Assembly调用链的安全检查
这样做的好处在于：可以大大丰富SQL Server的对象系统。
相信很多T-SQL设计人员在进行数据库设计的时候，会碰到因为相对非常有限的数据类型无法描述业务对象的情况。但有了CLR的支持，SQL Server 2005可以描述的对象系统基本上扩展为无限。但是，笔者这里根据经验提醒用户在使用该功能的时候要注意如下几个内容：
1. 设计新的数据对象要考虑到中间结果的存储问题。
2. 涉及到查询的时候还是要考虑采用T-SQL，这主要是出于效率问题。
3. 尽可能考虑到事件、Delegate回调对于处理性能的影响，不是必要的话尽量不用。
可以把整个开发的流程完全集成到统一的Visual Studio 2005中，全开发生命期可以在一个框架下完成。
更深层次讲，在完成统一个项目的时候，可以充分利用CLR进行复杂数据结构的计算能力效率和T-SQL的关系数据处理能力优势。
开发基于CLR的数据库对象
通过CLR的集成，可以在SQL Server 2005中建立如下的一些数据类型：
Scalar-valued user-defined functions (scalar UDFs)
Table-valued user-defined functions (TVFs)
User-defined procedures (UDPs)
User-defined triggers
上述四个类型算是基本的数据类型，因为它可以直接地映射到类的公共静态方法，除此之外还可以定义更为复杂的用户聚合函数。由于受到访问能力的限制，在SQL Server 2000中用户自定义函数能访问的对象有限，但是SQL Server 2005借助.NET平台甚至于可以把一些计算通过协调远端的Web Service一并完成。
笔者认为，在SQL Server 2005平台上，开发人员的思维要具有扩展性，不仅要考虑SQL Server 本身支持的内容，还要考虑到Windows平台支持的内容、企业内部SOA其他应用的支持，直至整个Internet环境下的任何可以用资源。
图3：CLR支持后扩展数据对象的资源分布
相对而言，开发User-Function和User-Defined Procedure都是比较容易，这里笔者就开发CLR 触发器作些说明。正如大家所知，Trigger主要包括两类：“DML 触发器”和“DDL 触发器”。DML触发器主要在DELETE、UPDATE、INSERT的时候触发，DDL 触发器则会在CREATE、ALTER、DROP的时候触发。在使用T-SQL编写触发器的时候可以通过INSERTED和DELETED这两个虚表，结合COLUMN_UPDATED()函数完成DML事件的响应。在集成了CLR之后，用.NET语言写触发器可以访问如下内容：
继续访问DELETED和INSERTED这两个虚表；
通过UPDATE操作，判断哪些列受到了修改；
通过访问数据库对象获得DDL的执行语句；
除此而外，开发CLR 触发器的时候还可以通过SqlContext.TriggerContext获得当前操作的上下文，明确究竟是DML的INSERT、UPDATE、DELETE，还是DDL的CREATE、DROP、ALTER操作。
代码示例1：INSERT或DELETE操作的DML触发器写法
SqlConnection connection = new SqlConnection (context connection = true);
connection.Open();
SqlCommand command = connection.CreateCommand();
command.CommandText = SELECT * from + inserted;
代码实例2：判断哪些列被UPDATE
reader = command.ExecuteReader();
reader.Read();
for (int columnNumber = 0; columnNumber < triggContext.ColumnCount; columnNumber++)
{
pipe.Send(Updated column
+ reader.GetName(columnNumber) + ?
+ triggContext.IsUpdatedColumn(columnNumber).ToString());
}
reader.Close();
代码实例3：通过访问Context判断DLL操作的内容
using System;
using System.Data;
using System.Data.Sql;
using Microsoft.SqlServer.Server;
using System.Data.SqlClient;
using System.Data.SqlTypes;
using System.Xml;
using System.Text.RegularExpressions;
public class CLRTriggers
{
public static void DropTableTrigger()
{
SqlTriggerContext triggContext = SqlContext.TriggerContext;
switch(triggContext.TriggerAction)
{
case TriggerAction.DropTable:
SqlContext.Pipe.Send(Table dropped! Heres the EventData:);
SqlContext.Pipe.Send(triggContext.EventData.Value);
break;
default:
SqlContext.Pipe.Send(Something happened!
Heres the EventData:);
SqlContext.Pipe.Send(triggContext.EventData.Value);
break;
}
}
}
SQL Server 2005上的ADO.NET 2.0
SQL Server 2005对于应用开发业提供了一系列新的功能，不过很多需要通过ADO.NET 2.0来访问。根据笔者的经验，如果您确定您的产品或者项目依托于SQL Server 2005，而不是做数据库产品无关的通用产品的话，完全可以考虑这些新的特性，但是要注意这些特性很可能会改变您的很多应用架构。
不会影响到系统构架的新特性如下：
（1）新的数据类型，包括XML数据；
（2）支持Snapshot级的事务隔离级别；
（3） 支持系统快速高可用功能的Mirroring；
但是，下面一些功能将会影响到您的系统架构：
（1）一步的SQL Server访问
（2）MARS （Multiple Active Result Set）,不仅可以让您复用与数据库的连接，而且还可以在源数据更新的时候，主动根据SQL Server触发更新。
事务的控制上，ADO.NET 2.0可以借助SQL Server自己的事务机制或者System.Transactions的支持，可以用非常简单的方式使用本地或者分布式事务。如果你的数据操作仅仅限于当前一个固定的SQL Server，那么笔者建议您采用Promotion的轻量级交易机制。你所要做的就是在SqlConnection的ConnectionString属性定义时增加一个Enlist关键字即可，这样当你的ADO.NET访问涉及DML操作时，CLR会自动为您增加一个事务，保证操作的原子性。但如果你的操作不仅仅限于当前SQL Server，还要访问其他异构数据库或者队列之类的其他对象，那么您需要分布式事务的支持，这时候您需要在DTC的调度下，同时使用SQL Server 2005本地事务、System.Transactions和System.Data.
[1] [2] 下一页
