图解“管道过滤器模式”应用实例：SOD框架的命令执行管道
管道和过滤器
管道和过滤器是八种体系结构模式之一，这八种体系结构模式是：层、管道和过滤器、黑板、代理者、模型-视图-控制器（MVC） 表示-抽象-控制（PAC）、微核、映像。
管道和过滤器适用于需要渐增式处理数据流的领域，而常见的“层”模式它 能够被分解成子任务组，其中每个子任务组处于一个特定的抽象层次上。
按照《POSA(面向模式的软件架构)》里的说法，管道过滤器（Pipe-And-Filter）应该属于架构模式，因为它通常决定了一个系统的基本架构。管道过滤器和生产流水线类似，在生产流水线上，原材料在流水线上经一道一道的工序，最后形成某种有用的产品。在管道过滤器中，数据经过一个一个的过滤器，最后得到需要的数据。
管道&过滤器模型的基本部件都有一套输入输出接口。每个部件从输入接口中读取数据，经过处理，将结果数据置于输出接口中，这样的部件称为“过滤器”。这种模型的连接者将一个过滤器的输出传送到另一个过滤器的输入，
我们把这种连接者称为“管道”。在这种模型中，过滤器必须是独立的实体，每一个过滤器的状态不受其它过滤器的影响，并且，虽然人们对过滤器的输入输出有一定的规定，但过滤器并不需要知道向它提供数据流的过滤器和
它要提供数据流的过滤器的内部细节。任何两个过滤器，只要它们之间传送的数据遵守共同的规约就可以相连接。
每个过滤器都有自己独立的输入输出接口，如果过滤器间传输的数据遵守其规约，只要用管道将它们连接就可以正常工作。
查询的关注点
基于以上管道和过滤器特点，它为处理数据流的系统提供了一种良好的结构，每一个处理步骤封装在一个过滤器组件中，数据通过相邻的过滤器之间的管道传输。在程序处理中，也有类似的这种数据流，最常见的就是命令处理的数据流，它从最开始的查询命令，到最后的结果输出，会经过多个步骤，以ADO.NET来说，执行一个查询会经过以下过程：
查询命令：
- 获取数据集：
- 打开数据库连接 IDbConnection
- 创建命令对象 IDbCommand
- 创建数据适配器 IDataAdapter
- 填充数据集 IDataAdapter.Fill(DataSet)
- 关闭数据库连接
- 返回数据集 DataSet
- 获取数据阅读器
- 打开数据库连接 IDbConnection
- 创建命令对象 IDbCommand
- 执行数据阅读器查询 IDbCommand.ExecuteReader
- 返回数据阅读器 IDataReader
- 关闭数据库连接
非查询命令：
- 打开数据库连接 IDbConnection
- 创建命令对象 IDbCommand
- 执行查询 IDbCommand.ExecuteNonQuery()
- 关闭数据库连接
- 查询前
- 查询中
- 查询后
- 查询异常
SOD框架的命令处理管道
命令处理接口
/// <summary> /// 查询命令处理器接口 /// </summary> public interface ICommandHandle { /// <summary> /// 获取当前适用的数据库类型，如果通用，请设置为 UNKNOWN /// </summary> DBMSType ApplayDBMSType { get; } /// <summary> /// 执行前处理，比如预处理SQL，补充设定参数类型，返回是否继续进行查询执行 /// </summary> /// <param name="db">数据库访问对象</param> /// <param name="SQL"></param> /// <param name="commandType"></param> /// <param name="parameters"></param> /// <returns>返回真，以便最终执行查询，否则将终止查询</returns> bool OnExecuting(CommonDB db, ref string SQL, CommandType commandType, IDataParameter[] parameters); /// <summary> /// 执行过程中出错情况处理 /// </summary> /// <param name="cmd"></param> /// <param name="errorMessage"></param> void OnExecuteError(IDbCommand cmd, string errorMessage); /// <summary> /// 查询执行完成后的处理，不管是否执行出错都会进行的处理 /// </summary> /// <param name="cmd"></param> /// <param name="recordAffected">命令执行的受影响记录行数</param> long OnExecuted(IDbCommand cmd, int recordAffected); }
一图胜千言，先看下面的“SOD框架命令处理管道”图：
由前面接口的定义并结合这个图，可以看到查询命令在“数据访问”这个管道里面流动过程：
- 首先，它在 OnExecuting 这个过滤插口位置改变命令的行为特征，比如SQL预处理，终止查询等，发起异步操作等；
- 接着，查询命令由Ado.Net进行处理，而此时是很有可能发生查询错误的情况的，那么提供一个OnExecuteError 过滤插口，让错误信息可以被一些过滤器使用，比如查询操作日志组件；
- 最后，不论前面命令执行是否成功，命令执行完了还需要进行一些其它的处理，那么提供一个OnExecuteError 过滤插口，比如观察命令执行的结果行/影响行，命令的执行时间，返回异步通知等。
根据这里定义的命令执行管道接口，最典型的实现就是可以用来记录查询日志，比如下面的 CommandExecuteLogHandle 类：
/// <summary> /// 命令执行日志处理器，可以记录SQL和参数，执行时间等信息 /// </summary> public class CommandExecuteLogHandle :ICommandHandle { /// <summary> /// 初始化一个命令执行日志处理器 /// </summary> public CommandExecuteLogHandle() { this.CurrCommandLog = new CommandLog(true); //这里需要进行一些初始化检查，设置日志路径等 if (CommandLog.DataLogFile == null) CommandLog.DataLogFile = "~/sql.log"; CommandLog.SaveCommandLog = true; } public CommandLog CurrCommandLog { get; private set; } public bool OnExecuting(CommonDB db, ref string SQL, CommandType commandType, IDataParameter[] parameters) { this.CurrCommandLog.ReSet(); return true; } public void OnExecuteError(IDbCommand cmd, string errorMessage) { CurrCommandLog.WriteErrLog(cmd, "AdoHelper:" + errorMessage); } public long OnExecuted(IDbCommand cmd, int recordAffected) { long elapsedMilliseconds; CurrCommandLog.WriteLog(cmd, "AdoHelper", out elapsedMilliseconds); CurrCommandLog.WriteLog("RecordAffected:"+recordAffected , "AdoHelper"); return elapsedMilliseconds; } public DBMSType ApplayDBMSType { get { return DBMSType.UNKNOWN; }
} }
注意，这里 ApplayDBMSType 返回 UNKNOW，表示当前接口实现类性适合于任意数据库查询的情况。
另外，日志过滤器内部使用了框架内置的 CommandLog 类，它可以异步的记录SQL执行情况，并能记录查询时间大于某个值的查询，详细请看《PDF.NET的SQL日志》。
再看下面，我们实现一个用于处理Oracle查询的“过滤器”组件，它会在查询开始前，对SQL进行一些预处理，比如将本来使用于SQLSERVER的SQL语句格式，处理成Oracle特有的格式：
/// <summary> /// 自定义的Oracle命令处理器，用于处理特殊的字段名大写问题 /// </summary> public class OracleCommandHandle : ICommandHandle { public bool OnExecuting(CommonDB db, ref string sql, System.Data.CommandType commandType, System.Data.IDataParameter[] parameters) { sql= sql.Replace("[", "").Replace("]", "").Replace("@", ":").ToUpper(); //设置SQLSERVER兼容性为假，避免命令对象真正执行的时候再进行Oracle的查询语句的预处理。 db.SqlServerCompatible = false; //返回真，以便最终执行查询，否则将终止查询 return true; } public void OnExecuteError(System.Data.IDbCommand cmd, string errorMessage) { } public long OnExecuted(System.Data.IDbCommand cmd, int recordAffected) { return 1; } public PWMIS.Common.DBMSType ApplayDBMSType { get { return PWMIS.Common.DBMSType.Oracle; } } }
注意：上面这个实现类，指明了当前命令执行过滤器组件，仅使用于Oracle数据库，当前如果是其它数据库类型，会忽略该过滤器组件。
除此之外，是不是还可以写一个过滤器组件，监视下当前查询是否执行成功，如果成功，将查询的SQL和参数发送到消息队列，进行异步更新其它数据库？
开闭原则
所以，SOD框架的“命令执行管道”给予了最终用户在不改变原有数据访问组件的内部实现的情况下，一个监视和处理命令执行过程的“窗口”，一个或者多个对查询命令的“过滤器”组件，这正是面向对象原则之一的开闭原则。
我们来看下百度百科对开闭原则的解释：
开闭原则（OCP）是面向对象设计中“可复用设计”的基石，是面向对象设计中最重要的原则之一，其它很多的设计原则都是实现开闭原则的一种手段。 遵循开闭原则设计出的模块具有两个主要特征： （1）对于扩展是开放的（Open for extension）。这意味着模块的行为是可以扩展的。当应用的需求改变时，我们可以对模块进行扩展，使其具有满足那些改变的新行为。也就是说，我们可以改变模块的功能。 （2）对于修改是关闭的（Closed for modification）。对模块行为进行扩展时，不必改动模块的源代码或者二进制代码。模块的二进制可执行版本，无论是可链接的库、DLL或者.EXE文件，都无需改动。
既然命令执行管道如此有用，我们该如何使用呢？还是直接看示例代码比较简单：
/// <summary> /// 用来测试的本地 数据库上下文类 /// </summary> public class MyOracleDbContext : DbContext { public MyOracleDbContext() : base("local") { //local 是连接字符串名字 //注册日志处理器和Oracle命令处理器 base.CurrentDataBase.RegisterCommandHandle(new CommandExecuteLogHandle()); base.CurrentDataBase.RegisterCommandHandle(new OracleCommandHandle()); } #region 父类抽象方法的实现 protected override bool CheckAllTableExists() { //创建用户表 CheckTableExists<User>(); return true; } #endregion }
在这个 MyOracleDbContext 类中，我们注册了2个过滤器组件：日志过滤器和Oracle命令过滤器。
如果当前连接配置名 local 对应的数据库访问提供程序不是Oracle了怎么办？
不用担心，前面说过， Oracle命令过滤器仅对Oracle数据访问有效，其它数据库访问会忽略，而日志过滤器组件它是适用于任何数据库访问的。
上面的示例代码中，CurrentDataBase 对象其实就是 SOD框架的 AdoHelper对象，所以，只要你使用SOD框架，那么不管你使用的是框架的ORM，SQL-MAP，Data Controls功能，甚至是最简单的“SqlHelper”类应用，你都可以享受到SOD框架的“命令执行管道”带给你d便利！
与“观察者模式”的区别
.NET框架中，对观察者模式最常见的实现就是“事件”，事件可以实现监视某个对象的改变情况然后发起事件通知，最后由事件处理程序完成处理。在本文描述的查询处理场景中，也可以在查询处理前，处理后，发生异常这3个“观察点”发起事件，并且，事件也可以实现“多播”，一个事件可以由多个事件处理程序来处理。所以，从这个意义上来说，“管道-过滤器”模式跟“观察者”模式功能上很相似的，但为何SOD框架不选择后者来实现呢？
我认为，主要区别有以下几个方面：
在架构层面上，
“管道-过滤器”模式通常用于架构设计层面，是一种“架构模式”，比如分层架构；而观察者模式一种面向对象编程的模式，运用的领域不一样。
“管道-过滤器”模式让架构实现松耦合；而观察者模式的观察者和被观察者之间，往往是紧密耦合的关系。
在具体使用形式上，
“架构模式”可以通过配置文件来提供附件的一种功能实现，比如ASP.NET的HttpHandle,ASP.NET MVC的Controller上的Filter等，所以它的实现是松耦合的；
而观察者模式往往体现在编写的代码中，用事件来处理代码来实现，所以它往往是紧耦合的。
在业务语义上，
“管道-过滤器”是用于处理流动的载体的，比如数据，信息或其它具有流动特性的物体，方便进行多环节，多层次的拦截或者加工处理，并且每个处理环节都有序的，流动和有序，这是这类业务最重要的特征；
“事件”处理的客体范围更广，事件的客体没有固定的形态，事件的发生和处理可能都是无序的。
其它方面的考虑，事件使用前总是需要声明事件挂钩，会多增加一些代码量，并且使用完成之后，往往还需要解除挂钩，否则可能发生内存泄漏，请参见 我另外一篇文章《Release编译模式下，事件是否会引起内存泄漏问题初步研究》。
总结
所以，在当前这个数据查询的场景中，对于查询命令的处理，采用“管道-过滤器”模式来实现一个命令执行管道，是最合适的，它让人在业务语义上更加明确，并且使用上更加灵活，代码实现量也最小，而且不需要修改原有的代码实现，符合开闭原则。
到目前为止，我还没有看到其它 数据处理框架/ORM框架 比较明确的提供了关注和干预组件内部查询执行过程的功能，都只能进行外部的拦截，如果你有这样的需求，来试试SOD框架带给你的灵活和自由吧！
附注：
SOD不仅仅是一个ORM，它还有SQL-MAP和DataControl，具体可以看框架官网 http://www.pwmis.com/sqlmap ，9年历史铸就的成果，坚固可靠。
非常感谢你看到这里，相信你初步了解了SOD框架的基本功能，如果您还有其它问题，欢迎你在项目的开源网站 http://pwmis.codeplex.com的讨论区发帖，或者去官方博客相关文章回帖也可。
