钝化程序、逻辑冻结、冻结程序的延续、瞬间转移

.NET框架设计(三：高级框架架构模式)—钝化程序、逻辑冻结、冻结程序的延续、瞬间转移

阅读目录：

1.开篇介绍

2.程序书签（代码书签机制）

2.1ProgramBookmark 实现（使用委托来锚点代码书签）

2.2ProgramBookmarkManager书签管理器（对象化书签集合的处理，IEnumerable<T>书签管理）

3.可恢复语句组件（将语句对象化）

3.1可恢复语句组件管理器（将可恢复语句视为普通的对象成员，IEnumerable<T>可恢复语句组件）

3.2可恢复语句组件运行时（Program CLR（简介））

3.3可恢复语句逻辑配置（规则的配置（简介））

3.4可恢复语句逻辑传输（将逻辑语句对象远程传输（简介））

4.DomainModel规则引擎（规则持久化后管理配置（简介)）

1】开篇介绍

这一篇文章我早准备写的，迟迟未写的原因是它过于抽象不太容易表达，也很难掌握；之前对它的理解还处于比较简单的功能性上，但是最近随着对领域驱动设计及架构的研究，设计思想有了一个提升对它的理解也有了一个更清晰的轮廓，所以才敢下手去写，这么好的一篇文章不能搞砸了；


我相信这篇文章绝对让你对 .NET框架设计 感兴趣，框架设计思想其实真的很美，让人陶醉；

2】程序书签（代码书签机制）

美好的一切都要有一个良性的开始，程序的钝化少不了对程序的逻辑保存的功能；有一个连续的调用穿过N个方法，方法一调用方法二，方法二调用方法三，这样的调用层次是根据业务的需求来定的，就好比一个复杂的业务逻辑这样的处理下去合情合理；


试想一下，我们要想将程序的逻辑流程钝化肯定是少不了对逻辑调用的保存；原本的程序逻辑是线程本地的执行路径，属于.NETCLR直接管理的，依赖于栈的执行，所以我们无法干预其生命周期过程，那么我们只有将它们对象化后才能由我们自己操控；

图1：



上图的意思是说在一个流程的开始到结束基本上三个重要环节，Begin\Processs…\End过程，在每个过程中需要不同的处理逻辑，在图的偏上方，我们有三个ProcessName名称的小方块表示程序的调用顺序，ProcessName1调用ProcessName2调用ProcessName3；

在ProcessName2的上面我们加了一个Bookmark的标记，表示我们这里所说的代码书签，通过代码书签我们就可以记录下本次执行到哪里了，就好比我们在看书的时候都有一个买书时赠送的书签卡，我们看到哪里就把这个书签卡插在那里，当下次要看的时候直接找到这个书签卡继续看；

这里的代码书签跟这个是一样的道理，理论就是这些我们下面通过示例代码来亲身体验一下这种设计模式；

2.1】ProgramBookmark 实现（使用委托来锚定代码书签）

委托是天生的方法标签，通过委托我们完全可以将一个实例的方法直接锚定下来；


我们来构造代码书签对象：

?
这段代码是对代码书签的抽象，构造函数传入一个代码书签的名称、书签所表示的物理代码锚点，Payload是表示每次执行物理代码时的输入参数；

上面代码看似简单其实很不简单，它的背后隐藏着一个很大的设计思想：


下面我们来看一下代码书签有多巧妙，我们来构造一个简单的示例代码，当然你完全可以设计的很复杂很强大，这里毕竟是传递这种设计思想为主；

?
这个类是一个简单的模拟检查订单的一系列的业务流程；

图2：



上图能看见流程顺利执行完毕了，那么我们来解释一下重要的代码片段；

图3：



在第一个流程里面我们构造一个通往下一个流程的 ProgramComponent.ProgramBookmark 对象，如果这里出现关于流程无法继续下去的条件就可以不创建往下执行的代码书签；在第二流程里面我们获取第一个流程设置的参数，这里是一个Bool值，可以用来判断上一个执行是否成功等信息；

2.2】ProgramBookmarkManager书签管理器（书签集合的处理，IEnumerable<T>书签管理）

上一节我们完成了对代码书签的抽象实现，但是代码还有很多值得抽象设计的地方，上面的代码中最不太理解的地方就是对书签集合的操作上，很不OO；

那么这一节我们将把它改进，形成OO方式的调用，先看一下哪里不太理解；

图4：



第一个地方就是在声明ProgramCompoent.ProgramBookmark集合上，这样写问题太大了，无法进行扩展改进；然后就是在构造函数中，我们使用了很长一段代码来构造一个ProgramCompoent.ProgramBookmark对象，完全可以减少很多；还有就是在StartCheck方法的内部中进行循环调用书签的代码，也很有问题，完全可以封装在内部实现，外部直接一个CurrentProgram属性执行就行了；

那么对这些问题我们其实少一个ProgramCompoent.ProgramBookmark的管理器对象ProgramCompoent.ProgramBookmarkManager对象，它负责管理所有跟ProgramCompoent.ProgramBookmark对象相关的工作；

?
书签管理器基本功能还算简单，主要的方法Resume是用来恢复指定的书签的；再来看一下订单检查流程调用；

?
是不是比之前的代码好多了，我感觉是好多了，当然还有很大的重构空间；

这里其实已经可以和链式编程的机制挂钩了，我们可以通过给书签管理器添加N个扩展方法来使书签管理器具有跟链式的调用；

3】可恢复语句组件（将可恢复语句对象化）

要想把所有的调用都拆开来使用松散的方式组合，通过使用书签机制基本上能将所有的方法进行松散组合；那么我们还需要将逻辑语法进行对象化才能做到无死角的松散；


其实对 企业应用架构 中的 规约模式 有所了解的人应该会比较熟悉这一节的内容，跟规约模式很像，但不是一个东西，侧重点不同；语句组件全面的概念是将所有的调用都对象化，包括一些输出、输入、网络调用等等，这样才是全部的语句组件定义，还记得我们上面的订单检查对象嘛，那个也是语句组件之一；

我们来构造可恢复语句组件对象；

ProgramComponent.LanguageComponent.LanguageComponent类代码：

?
ProgramComponent.LanguageComponent.LanguageComponentBlock类代码：

?
ProgramComponent.LanguageComponent.IfElseLanguageComponent类代码：

?
检查流程代码，OrderCheckFlows\OrderSubmitFlows类代码：

?
调用代码：

?
一切都已经被对象化，我们来看一下逻辑；

图5：



这里的返回值决定了后面要执行的语句组件的路径，如果是true，则应该检查OrderCheckFlows流程；

图6：



如果是false，则应该检查OrderSubmitFlows流程；

图7：



可恢复语句对象模型基本构造完成，当然复杂的问题还需要仔细的去分析设计，这里只是一个简单的示例；

3.1】可恢复语句组件管理器（将可恢复语句视为普通的对象成员，IEnumerable<T>语句组件）

跟代码书签管理器一个道理，这里我们也可以实现一个LanguageComponentManager来对LanguageComponent管理，当然也要看需要不需要；可恢复语句管理器其实有很多文章可以做，因为它是所有语句组件的中心，这对于后面的持久化有很大的用处；

//由于内容比较多且相当抽象，下一篇文章介绍；

3.2】可恢复语句组件运行时（Program CLR）

所有的语句代码都已经被对象化，但是在运行时需要一个中心来管理这些被对象化的语句组件，因为我们要脱离对栈的依赖；一组语句组件是单个示例流程的一部分，但是我们可能会存在很多一起并行运行的流程，所以这是必须要提供的运行时；

//由于内容比较多且相当抽象，下一篇文章介绍；

3.3】可恢复语句逻辑配置（规则的配置）

领域驱动设计在使用规约模式的时候会存在动态配置的需求，可以参见这里的语句组件模型，让规约最大化的提供配置；

//由于内容比较多且相当抽象，下一篇文章介绍；

3.4】可恢复语句逻辑传输（将可恢复语句对象远程传输）

//由于内容比较多且相当抽象，下一篇文章介绍；

4】DomainModel规则引擎（规则持久化后管理配置）

//由于内容比较多且相当抽象，下一篇文章介绍；

示例DEMO地址：http://files.cnblogs.com/wangiqngpei557/ConsoleApplication3.zip

作者：王清培

出处：http://www.cnblogs.com/wangiqngpei557/

本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。