重提一下WXWinter的博文：

     While与Replicator可以重复执行其子Activity，While与Replicator在每次重复使用Activity时，并不是将其重置到初始状态。而是克隆原始Activity，每个克隆的Activity都单独进行管理。不会干扰其他克隆的Activity。这些克隆的Activity每一个都要有自身的 AEC 来管理状态。

     这段描述没有问题，有两点还没说清楚：

     1、克隆的Activity的可见性。

     2、在什么时候克隆Activity。

     我们从WXWinter的例二入手，例二没有达到预期目的的根本原因就是克隆的Activity的可见性。

     例一中是在流程中给活动实例的MyProperty属性做++操作的，在流程中只能看到真正的Activity1的活动实例，是不可能看到活动的副本的，所以这里++操作就是针对真正的Activity1的活动实例的。而例二中，由于将给活动实例的MyProperty属性做++操作封到了ActivityLibrary里面，运行时++操作是针对活动的副本进行的，所以根本不会影响到真正的活动实例。

     我们经常要封ActivityLibrary的同志就要注意了，必须使用this.Parent.GetActivityByName(this.Name)才能取到真正的活动实例，GetActivityByName的作用是根据指定的类型名返回当前活动及其子运行活动的活动实例。

     问题二什么时候克隆Activity，在串行情况下，在每次执行序列之前克隆Activity，证据是在副本活动中用一下代码：

     private void codeActivity1_ExecuteCode(object sender, EventArgs e)
        {
            Activity1 a1 = this.Parent.GetActivityByName(this.Name) as Activity1;
            a1.MyProperty++;
            Console.WriteLine(MyProperty);
        }

     可以发现副本的MyProperty值也是变化的。

     在并行情况下就是在最初全部克隆好了。

工作流队列用于在宿主程序或工作流外部服务与工作流中的活动之间传递消息。WF本质论里面写的很含糊，通过下面的例子可以很好的理解工作流队列的使用。

例子主要功能是，一流程运行到ReadLine活动处，等待用户在控制台的输入，如果用户没有输入，则流程会钝化，有一个书签（其实就是对事件的处理方法）会加到工作流队列的QueueItemAvailable事件上。

下面首先看ReadLine这个活动，解释看注释。

using System;

using System.Workflow.ComponentModel;

using System.Workflow.Runtime;

namespace EssentialWF.Activities {

  public class ReadLine : Activity {

    private string text;

    public string Text {

      get { return this.text; }

    }

protected override void Initialize(IServiceProvider provider) {

//活动初始化时就用活动名字创建，不用担心多个实例间的重名情况，因为消息队列是跟着流程实例走的

      WorkflowQueuingService qService =(WorkflowQueuingService)provider.GetService(typeof(WorkflowQueuingService));

      if (!qService.Exists(this.Name))

        qService.CreateWorkflowQueue(this.Name, true);

    }

    protected override ActivityExecutionStatus Execute(ActivityExecutionContext context) {

      WorkflowQueuingService qService = context.GetService<WorkflowQueuingService>();

      //尝试执行获取用户输入，如果有用户输入，Dequeue方法就能获取的到

          //并将活动的执行状态置为结束

 WorkflowQueue queue = qService.GetWorkflowQueue(Name);

      if (queue.Count > 0) {

        this.text = (string)queue.Dequeue();

        return ActivityExecutionStatus.Closed;

      }

           //尝试执行没有成功，给队列的QueueItemAvailable事件（此事件会在消息入队列时触发）加上处理方法

           //并将活动的执行状态置为运行中

      queue.QueueItemAvailable += this.ContinueAt;

      return ActivityExecutionStatus.Executing;

    }

         //下面都很好理解了，不说了

    void ContinueAt(object sender, QueueEventArgs e) {

      ActivityExecutionContext context = sender as ActivityExecutionContext;

      WorkflowQueuingService qService = context.GetService<WorkflowQueuingService>();

      WorkflowQueue queue = qService.GetWorkflowQueue(Name);

      this.text = (string)queue.Dequeue();

      context.CloseActivity();

    }

    protected override void Uninitialize(IServiceProvider provider) {

      WorkflowQueuingService qService = (WorkflowQueuingService)provider.GetService(typeof(WorkflowQueuingService));

      if (qService.Exists(this.Name))

        qService.DeleteWorkflowQueue(this.Name);

    }

  }

}

再看我们的宿主程序怎么和ReadLine活动配合。

string s = Console.ReadLine();

instance.EnqueueItem(“rl1”,s,null,null);//这行代码就是向队列中加入消息，rl1是活动的名称，s是消息的数据信息，后两个参数是用于传递消息后接受反馈的通知。

首先sa登录查询分析器，执行Dbcc traceon(1204, 3605, -1)，其中参数1204代表返回参与死锁的锁的类型以及当前受影响的命令，3605代表trace到的信息必须记录到日志中，-1代表返回当前所有打开的跟踪标记的状态。有几点要注意，1、事件探查器是跟不出死锁的sql的，因为它只是记录执行过的sql，而这些在事务里面死锁的sql都会被回滚的；2、只有在打开这些标记后数据库才会记录日志，打开这些标记会影响数据库性能，记得用完了使用Dbcc traceoff（标记号）关掉。

接着就是再现这个死锁了，让实施人员在远程找5、6个人同时点这个功能，嘿嘿，不错，一下子就出来了。将数据库日志发过来，一般在Program Files\Microsoft SQL Server\MSSQL.4\MSSQL\LOG\ERRORLOG下。打开文件仔细看发现下面的日志。

2008-05-31 10:10:46.20 spid5s      Node:1

2008-05-31 10:10:46.20 spid5s      RID: 5:1:6815:21               CleanCnt:3 Mode:X Flags: 0x2
2008-05-31 10:10:46.20 spid5s       Grant List 2:
2008-05-31 10:10:46.20 spid5s         Owner:0x3711E420 Mode: X        Flg:0x0 Ref:1 Life:02000000 SPID:59 ECID:0 XactLockInfo: 0x387A26FC
2008-05-31 10:10:46.20 spid5s         SPID: 59 ECID: 0 Statement Type: DELETE Line #: 133
2008-05-31 10:10:46.20 spid5s         Input Buf: RPC Event: Proc [Database Id = 5 Object Id = 1254295528]
2008-05-31 10:10:46.20 spid5s       Requested By:
2008-05-31 10:10:46.20 spid5s         ResType:LockOwner Stype:'OR'Xdes:0x533EBC80 Mode: S SPID:67 BatchID:0 ECID:0 TaskProxy:(0x1F092374) Value:0x2962ae40 Cost:(0/0)
2008-05-31 10:10:46.20 spid5s     
2008-05-31 10:10:46.20 spid5s      Node:2

2008-05-31 10:10:46.20 spid5s      KEY: 5:72057594056212480 (fc0199b9be7a) CleanCnt:2 Mode:S Flags: 0x0
2008-05-31 10:10:46.20 spid5s       Grant List 2:
2008-05-31 10:10:46.20 spid5s         Owner:0x2028AD80 Mode: S        Flg:0x0 Ref:1 Life:00000000 SPID:67 ECID:0 XactLockInfo: 0x533EBCA4
2008-05-31 10:10:46.20 spid5s         SPID: 67 ECID: 0 Statement Type: SELECT Line #: 1
2008-05-31 10:10:46.20 spid5s         Input Buf: RPC Event: Proc [Database Id = 5 Object Id = 484053356]
2008-05-31 10:10:46.20 spid5s       Requested By:
2008-05-31 10:10:46.20 spid5s         ResType:LockOwner Stype:'OR'Xdes:0x387A26D8 Mode: X SPID:59 BatchID:0 ECID:0 TaskProxy:(0x576FE374) Value:0x1eb9ad20 Cost:(0/84)
2008-05-31 10:10:46.20 spid5s     
2008-05-31 10:10:46.20 spid5s      Victim Resource Owner:
2008-05-31 10:10:46.20 spid5s       ResType:LockOwner Stype:'OR'Xdes:0x533EBC80 Mode: S SPID:67 BatchID:0 ECID:0 TaskProxy:(0x1F092374) Value:0x2962ae40 Cost:(0/0)

Node1（SPID：59）拥有了一个资源的排他锁Mode: X ，而需要申请另一个资源的共享锁Mode: S，Node2（SPID：67）拥有了后一个资源的共享锁，请求前一个资源的排他锁。根据学校里的零星知识，还是能明白这个道理的。照理说这种情况是不会死锁的，但是如果在事务里，共享锁也会在事务结束以后才释放。

联机丛书上有一些信息可以利用来看这段日志。

类型列

"类型"列显示当前锁定的资源类型。

资源类型
描述

RID
用于锁定表中的一行的行标识符。

KEY
索引中的行锁。用于保护可串行事务中的键范围。

PAG
数据或索引页。

EXT
相邻的八个数据页或索引页构成的一组。

TAB
包括所有数据和索引在内的整个表。

DB
数据库。

资源列

"资源"列提供有关正被锁定资源的信息。

资源类型
描述

RID
表内已锁定行的行标识符。行由 fileid:page:rid 组合进行标识，其中，rid 是页中的行标识符。

KEY
SQL Server 内部使用的十六进制数字。

PAG
页码。页由 fileid:page 组合进行标识，其中，fileid 是 sysfiles 表中的 fileid，而 page 是该文件内的逻辑页码。

EXT
正被锁定的扩展盘区中的第一个页码。页由 fileid:page 组合进行标识。

TAB
由于 ObjId 列已包含表的对象 ID，所以没有提供任何信息。

DB
由于 dbid 列已包含数据库的数据库 ID，所以没有提供任何信息。

在 sp_lock 的结果集内，锁定的 RID 资源类型中的资源描述为 1:1225:2。这表明在 fileid 1 内、页码为 1225 的页中、行标识符为 2 的行上应用了锁。

最关键的信息我认为是

[Database Id = 5 Object Id = 1254295528]和[Database Id = 5 Object Id = 484053356]
指明了加锁的两个对象。

select  db_name(5)  结果为 cwbase_zclzj
连接 cwbase_zclzj帐套，
select object_name(484053356)  结果为  ： erp_LS_BillCodeRule_GenerateNewBillCode
select object_name(1254295528)  结果为： erp_LS_BillFlowNoRecords_NewRecordSave

原来是两个存储过程搞得鬼，在生成单据编号的时候出现了死锁，因为两者是放在同一个事物中，也就验证了我们上面的猜想。简单的处理办法是不要放到同一个事物中，其他的办法就让负责维护的同事去管吧。

就写到这里，其实日志里面的大部分咚咚还是看不懂，等待高人给予解释。如果分析中有什么不对的，也请各位回复指出，我也进一步学习一下。谢谢！

（1） 描述

内部交易流程，完成了整个业务过程之后是集中开票的过程。开票操作是批操作，至于哪些放到一批里面，这个规则不确定，可能由人决定，可能是一个月开一次票。

单纯的从业务发生发展角度来看，内部交易完成以后就应该是开票，以上的业务流程图很简单，如下：

展开来看，想要达到的运行效果类似于下图：

（2） 解决方案

a、 将内部交易和集中开票分到不同的业务流程上，本来这者就没有太紧密的联系，因此分到两个业务流程上也很自然。实现方式上，内部交易流程实例正常结束，之后由人参与决定哪些数据集中到一张发票上，激活开票流程。为了流程回溯，在数据汇合的时候应该记录内部交易流程和开票流程之间的关系。这种方案适用于内部交易流程和开票之间没有固定规则，需要人参与的场景。

b、 用多实例模式中的在运行时都不确定执行次数的方式来实现这个流程，内部交易流程是一个可重复执行的活动块，这个活动重复执行的次数是在运行时外部事件决定的，可能是时间，也可能是人参与产生的事件。如，在某些管理方法中是月结的，即是由时间作为外部事件，下图描述了这种情况。

上图的流程的启动条件是每月月初，并使能重复执行Scope块活动，每个内部交易开始激活一个执行线程，此内部交易流程结束后，整个Scope块活动仍然处于使能状态，直到结束条件‘时间到月末’成立，整个Scope块活动结束，然后进行集中开票。

（3） 含义引申

从上面的两个解决方案引出了一个问题，什么样的流程环节应该画在一个流程里面，而什么样的应该分开，这个是不是有选择的标准？是根据实施人员的经验来进行判断？那么两个不同水平的实施人员所定制的流程的可用性将有天壤之别。目前总结的标准或者说是策略包括：

a、 流程描述、展现的含义是不是清楚。在特定流程定制工具的约束下，是不是能表达出流程的本义。

b、 数据转换存不存在问题。在一个流程中，这个肯定不是问题，而分开了可能就有问题。

c、 流程回溯、数据跟踪的方便性，同上面一条的道理。

除了上述的选择标准的问题，还有一个问题不得忽视。如何保持流程之间的串联性，说白了就是如果是自动激活了流程，如何通知这个流程启动，而如果是由人激活的流程，那么如果去通知这个人。自然的联想就是通过消息中间件，其特征必须具备传达的可靠性、大吞吐量和回馈的准确性。微软的建议是使用Biztalk，那么就在这种假设下构建了如下的业务流程图。

上图表达了粗粒度的业务流程图，图中每个方块代表的是一个模块内的流程，而模块间的流程的互操作性由Biztalk的能力提供，主要依赖强大的Mapping做数据转换、抓取数据的BAM用来做数据跟踪、消息中间件的能力。

另一个问题是业务流程划分的力度不能过小，如果还是以一个功能点为一个业务流程的话，又回到了目前功能驱动的情况了。

（1） 描述

两条或更多的分支合并到单一的一条后续路径中，每一条使能进入分支都激活后续路径的一次执行线程。虽然多条分支在图形上是合并的，但是这个多路合并并不对这些分支激活的后续线程进行任何的同步。

（2） 抽象模型描述

多路合并的Flash动画

上图中，B和C是多路选择后的分支，这样的分支可以超过两个，假设还有E、F……，这样的分支在多路选择处不进行同步，每一个分支都会激活一次D的执行，即D（B）、D（C）、D（E）……，并且这些D的线程互不干扰。

（3） 业务场景举例

报销流程，假设分为三部分：住宿费、交通费、飞机票特殊报销。可能出现的情况有：住宿费+交通费；住宿费+交通费+飞机票特殊报销；交通费；交通费+飞机票特殊报销……

流程开始，首先填写报销申请（勾选报销的内容，三种费用中选择），之后流程根据勾选的内容激活后续的填写不同报销单的分支，最后每一张报销单都需要经过审批。

如果流程引擎没有实现多路合并我们可以变相的实现上面的功能。如下图：

但上述的实现有以下的不足：

a、 重复工作量，审批分明是同一个活动，非要分多个来画；

b、 无法进行统计，若要对审批这一活动的时间、数量等信息进行统计分析，那么分成了多个活动后就难于进行统计。

c、 资源的分配，假设审批是由一个岗位来负责，且任务压力应该在这个岗位上负载均衡，那么分成了多个活动后这个资源的分配也无从着手。

（4） 含义引申

多路合并的后续路径，是一些相同行为的执行线程，这就类似于另外一种模式——多实例模式。这些线程终有一个需要同步的时候，在业务场景中，这个同步就非常的复杂，如后续步骤为制证，这种业务可以分为以下情况，我们一一举例说明：

a、 强制一对一：一个审批后的单据生成一个财务凭证，那么这些多实例的线程暂时不同步，留到后续步骤。这种管理方式是比较常见的。

b、 强制多对一：同一个报销申请产生的报销单据，需要生成在一个财务凭证上。因此在制证前就需要同步。这种管理方式是比较常见的。

c、 任意多对多：在本场景中，这个不太可能发生，但在一般的物流业务中却非常常见。假设飞机票的审批比较严格，拖得时间比较长，另外两个报销单早批了，那么先将这两个生成同一个财务凭证。这种任意性的规则，一般都是通过人来判断的。

这样我们在为业务流程建模时，首先是定义“业务流程”，其次应该是识别流程中有哪些“业务活动”，并为“业务活动”定制一些属性，最后才是定义具体的流程。使用一套已经建立好了的“业务流程”来定制流程就变得非常的轻松，流程上关联业务流程，活动上关联业务活动，这样所有与业务相关的属性就都可以设置好。

先前版本的工作流将活动上不管是与业务相关的，还是与流程相关的属性一齐混杂在流程设计器上。这种实现方式有几大弊端：1、无法实现同一业务概念的复用，在一个活动上定的业务概念，需要在另一个相同业务意义的活动上原封不同的重定一遍。虽然我们实现了活动的复制，但我认为这种复制不是解决这种业务意义复用的很好方式。2、所有的与业务相关的实体都是独立于工作流系统之外的，在定义流程时将这些业务实体的设置记录在流程定义中。由于流程的版本控制，先前已经运行的流程定义是无法改变的，而业务实体又可能是会发生变化的，如单据的字段权限变化了（对于自定义表单这样生来就是为适应变化的，就更容易发生变化了），构件的参数又增加了一个等等，致使流程运行时业务上的改变得不到及时的体现，甚至运行不下去。3、流程运行结果，更通俗的讲可能是审批的结论、意见不能根据业务意义进行分类，明显的体现是审批结果打印时，所有的意见结论都罗列在一起（这个需求来源于OA项目组）。

       哪些活动属性应该放到“业务活动”上，我认为表单定义、表单权限设置（动作权限、字段权限），其他象外部工具、规则等也可以考虑放进来。

       工作流可以无区别的对待普通流程和OA使用的动态流程的权限设置，都包括表单参数设置、表单动作权限的设置、表单字段权限的设置。

       值得一提的是，像加签、会签、跳转等权限，我认为是纯粹的流程权限，不应该去表单的权限混为一谈，可以强制识别这些的流程引擎提供了的流程动态功能，并为其设置权限。

       对特殊性、向下兼容的考虑，在流程定义上仍然保留这些在“业务活动”添加的属性，在使用时首先查找具体活动上的定义，再查找业务活动上的定义。这样的同一“业务活动”对应的活动也可以有完全不同的特性，而且对于老版本的流程定义，即使没有在活动上关联业务活动，仍可以正常运行。

   首先想到的是业务流的流程实例的拆分和合并，流程是跟业务对象实例一一对应的，业务流中的业务对象有很多种，每种业务对象的实例之间存在拆分和合并的可能。如果对象实例数据合并了，则流程实例也需要合并；如果对象实例数据拆分了，流程实例也需要拆分。

   第二个想到的办法是，将实例的明细数据启动一个流程实例，这里仍需要解决一个问题，那就是各个环节的处理是以一个业务实例为单位的，将明细数据对应一个流程实例，需要提供组处理的功能，即一组任务项合并为一个任务，处理这个任务就完成一批任务。

   第三个办法就是不使用业务流的原理来处理。即一个单据的完整流程使用业务流系统，几个单据之间使用的是集成流，利用集成的方式来处理几个单据之间的流转。

  虽然办法有很多，但是那种是最好的方式呢？

        写在最后，这两种方法本质上原理是一致的，我个人觉得，如果对il掌握的非常好的话，第一种方法是非常爽的，即使是在项目现场，对一些小问题修改都是相当轻易的。由此还想到.net的安全性，对于非强命名的dll来说，这种il级别的修改都是有效的，但对于软件的保护是相当不利的，我们是很容易从il中找到验证正版的代码信息，直接去掉，重新编译就破解了；对于入侵者来说，也是很容易修改系统上.net程序的运行方式的。

在 MS DTC 术语中，执行者被称为事务管理器。在执行事务保护资源的事务中，其参与者（如关系数据库）被称为资源管理器。

应用程序对每个资源管理器的第一次调用确定应用程序的当前事务。例如，如果应用程序在使用关系数据库，它会调用 ODBC 接口，此接口将事务对象与 ODBC 连接关联起来。在此之后，所有通过此连接的数据库调用都会代表该事务执行，直到该事务结束为止。

当某个资源管理器首先代表某个事务工作时，会通过调用事务管理器“登记”到该事务中。随着事务的发展，事务管理器会跟踪每个登记到该事务中的资源管理器。

通常，应用程序用 Commit 事务方法来完成事务。如果应用程序无法完成，则调用 Abort 事务方法，该方法可以撤消事务的操作。如果应用程序失败，MS DTC 就会放弃此事务。

当应用程序成功地完成事务的工作后，它会调用 MS DTC 来“提交”事务。然后 MS DTC 会仔细检查“两阶段” “提交协议”，使所有已登记的资源管理器都提交。两阶段提交协议可确保所有的资源管理器提交此事务，或全都放弃此事务。在第一阶段，MS DTC 询问每个资源管理器是否“准备”提交。如果所有参与者都回答“是”，那么在第二阶段 MS DTC 将向所有参与者广播提交信息。如果事务的任何部分失败，或资源管理器响应准备请求失败，或资源管理器响应“否”，那么 MS DTC 将通知所有资源管理器该事务已被放弃。

昨晚，k一本叫“理工大风流史”的校园小说到两点，终于k完。

我不是一个矫情的人，但不由要写下下面一段矫情的文字。

小说前面都是风平浪静，如同所有校园小说一样，笑料+爱情+暴力+边缘性描写，怀疑现在的大学校园怎么都在走“蛊惑仔”的路线。

但最后毕业告别和无言的结局，还是在我心里搅和一下。“窗外，一张破旧的床单上几个大字，一起走过，在夏雨里浸开了墨迹”、“临行，为了逃避送站的痛苦，趁兄弟们熟睡时就悄悄地走了，只在美女墙画上留下，保重，和歪歪扭扭的签名”，联想到的就是网上颇为流行的毕业图组，此时，另一更强烈的念头滑过，“我们也要毕业了”，顿时酸楚。

黑暗中，胡乱的从桌上抓起zippo，让醇香的烟气走过喉咙，填补此刻的苍白。寂静的夜里，谁会在意一个大男孩的心声。

思绪不由飘到了千里之外的丁香校园，那里恐怕已是白雪皑皑了，而哥们们已是散落在天涯，我的大学生活好像也是刚刚开场就荒诞的谢幕了。可爱的超超估计还在为考研忙得焦头烂额；婆婆妈妈的ken还能在珠海沐浴和煦的海风；油光满面的睿睿在伟大首都孕育做官的美梦；老鼠估计还在骗人的中兴软件煎熬度日；红过脖子的DKF，差不多能满足当上他外国新娘的愿望；当然不能忘怀的还有那份已经飘散的爱情。

小说自然是高于生活，我们的大学生活也可以拿出来试比高。我们的寝室翻不出c cup和taotao，却也有成堆的臭袜子和肥硕的小强；我们没有方桌上成宿的扑克麻将，却也有水房洗衣机上熬夜赶程序，贩卖机里驮来夜宵，兄弟们共饮；我们没有草丛树林的风流韵事，却也有99多青涩的玫瑰；我们没有打架斗殴，却也有众志成城拿下篮球赛；我们没有网吧里数以月计的传奇奇迹，却也有KTV里的烂醉如泥……

回首过去，我们一起走过，我小心翼翼的将记忆收起；而面对未来，没有了朝夕相处的兄弟，该往哪里去，我无言以对。

1.1.1.1           Goal

国际化组件可以将非特定语言的字符串转化成特定语言的字符串，还可以通过反射的方式将某一界面上控件的文字换成特定语言的文字。

1.1.1.2           Context

1.1.1.3           Behavior View

1.1.1.4           Structure View

1.1.1.5           Other Specification

1.1.1.6           Best Practice

ResourceFactory fa = ResourceFactory.GetInstance();

            GspRM resourceManager = null;

            if (comboBox1.Text == "中文")

            {

                resourceManager = fa.GetRM("formui", "zh-cn");

                //resourceManager = fa.GetRM("aa","zh-cn");

                FormLanguageSwitchSingleton change = FormLanguageSwitchSingleton.Instance;

                change.ChangeLanguage(this, new System.Globalization.CultureInfo("zh-chs"));

            }

            else

            {

                resourceManager = fa.GetRM("formui", "en-us");

                FormLanguageSwitchSingleton change = FormLanguageSwitchSingleton.Instance;

                change.ChangeLanguage(this, new System.Globalization.CultureInfo("en-us"));

            }

            MessageBox.Show(resourceManager.GetLocalizeToken("result", "jane"));

  static TestConstructor()
  {
   Console.WriteLine("static");
  }

  internal TestConstructor()
  {
   Console.WriteLine("internal");
  }

  internal void test()
  {}

//  static void test()
//  {}
 }
 }

一下的来自google搜索：

　　静态构造函数是实现对一个类进行初始化的方法成员。它一般用于对静态数据的初始化。静态构造函数不能有参数，不能有修饰符而且不能被调用，当类被加载时，类的静态构造函数自动被调用。如：

using System.Data;
class Employee
{
　private static DataSet ds;
　static Employee()
　{
　　ds = new DataSet(...);
　}
　...
}

　　声明了一个有静态构造函数的类Employee。注意静态构造函数只能对静态数据成员进行初始化，而不能对非静态数据成员进行初始化。但是，非静态构造函数既可以对静态数据成员赋值，也可以对非静态数据成员进行初始化。

　　如果类仅包含静态成员，你可以创建一个private的构造函数：private TestClass() {…}，但是private意味着从类的外面不可能访问该构造函数。所以，它不能被调用，且没有对象可以被该类定义实例化。

对于上文的最后一点，我又试了一下。并发现,静态的构造函数在第一次对任意静态成员赋值时被调用。
 class Class1
 {
  /// <summary>
  /// 应用程序的主入口点。
  /// </summary>
  [STAThread]
  static void Main(string[] args)
  {
   Console.WriteLine("Will give A value");
   TestPrivateStatic.a = 3;
   Console.WriteLine("Done");
   TestPrivateStatic.a = 4;
   Console.ReadLine();
  }

public class TestPrivateStatic
 {
  public static int a;

  static TestPrivateStatic()
  {
   a = 2;
   Console.WriteLine("a has been given value");
  }
 }
 }

就这样了，平时总会发现一些细小的东西，没记下来真是一种损失，现在来弥补。

上周刚刚看完了nxbre，写了一个ppt给项目组评审，用来拟定我们GSP中的规则引擎的实现需求。
    不知为什么我上传不了文件，只好把ppt的内容贴出来给大家共享。大家如果这个开源项目感兴趣，可以留言索取。ppt中不可能把细节讲的很清楚，而且由于时间关系，只写了其中的flow engine,请见谅。

Nxbre的简介
 

Nxbre包括interface engine和flow engine

两种引擎的区别

the Flow Engine, which uses XML as a way to control process flow for an application in an external entity. It is basically a wrapper on C#, as it offers all its flow control commands (if/then/else, while, foreach), plus a context of business objects and results.

the Inference Engine, which is a forward-chaining (data driven) deduction engine and that supports concepts like Facts, Queries and Implications (as defined in RuleML 0.86 Datalog) and like Rule Priority, Mutual Exclusion and Precondition(as found in many commercial engines). It is designed in a way that encourages the separation of roles between the expert who designs the business rules and the programmer who binds them to the business objects.

两种引擎使用的场景

1.      the Inference Engine supports priority, mutual exclusions and pre-conditions,

2.      the Inference Engine uses a "standard" rule format (RuleML),

3.      the Inference Engine has an elaborated memory model with support for isolated deduction space.

4.      Interface Engine 更适合于知识库或专家系统，因为在这样的系统中，facts必须被保持

5.      Flow Engine 只是对一段逻辑进行了解析，并根据结果去做action

6.      The Flow Engine is really an instantaneous traversal of logical branches using transient data for evaluations of boolean expressions.

选择的理由

1.      在我们的GSP系统中，没有对fact保持的需求，没有通过规则优先级、互斥和前置条件的判断来选择规则

2.      Flow Engine 相对简单，易于维护

所以，应该Flow Engine是一个合适的选择

Flow Engine的介绍

加载和卸载规则集的API (BREImpl)

Init

Reset

数据操作的API（IBRERuleContext）

SetObject

GetObject

引擎执行的API (BREImpl)

Process

Stop

规则引擎基本遵循以下5个典型的步骤 

1.      创建规则引擎对象

2.      向引擎中加载规则集或更换规则集

3.      向引擎提交需要被规则集处理的数据对象集合

4.      命令引擎执行

5.      导出引擎执行结果，从引擎中撤出处理过的数据

Flow Engine中的规则文件

规则语言一般分为两类：

“面向程序技术”的规则语言，使用者是技术人员。在Flow Engine中是.bre文件（结构是businessRule.xsd规定的） ，引擎真正解析的也是这个文件。

“面向业务”的规则语言，使用者是业务人员。规则定制器应该生成这份文档。在Flow Engine中是.xbre文件（结构是businessRule.xsd规定的） 。

两种Schema的转换是由transformXRules.xsl文件规定的。

Flow Engine为加载规则文件提供了以下的类：IRulesDriver,AbstractRuelsDriver,BusinessRulesFileDriver,XSLTRulesFileDriver,XBusinessRulesFileDriver, XBusinessRulesStreamDriver, XBusinessRulesStringDriver

Flow Engine中的规则上下文

规则上下文中包含如下四块：

1.      RuleFactory集(hashtable),包含rule的解决方法，可以是默认的，也可以是自定义的

2.      Operator集(hashtable),包含可用的比较操作符，如：==,<,>等

3.      Result集(hashtable),包含result和用户初始的数据,lookupobject就是在result集中查找数据对象。每条<rule>都会产生一条result，每条result又会包含metadata和结果数据。metadata中包含产生这条result的rule的factory和param

4.      CallStack(stack),目前没发现有什么用，只是在往Result集中添加result的同时也往此中添加

支持上下文的主要类型：IBRERuleContext,AbstractBRERuleContext,BRERuleContextImpl

Flow Engine创建规则引擎对象 

构建BREFactoryConsole对象，他负责构建BREImpl对象，并向外发布引擎中出现的log和exception

构建BREImp对象之前，必须首先构建BREFactory,他负责将log和exception的代理挂到BREImp对象中的相应event上去

用IRuleDriver初始化BREImp对象

相关的类型： BREFactoryConsole，BREFactory，BREImp

Flow Engine加载规则集

在Flow Engine中rule（在.bre文件中用<rule>标签标识的部分）是一些用id唯一标识的对象。加载这些rule的方式有两种：

1.      在引擎初始的时候，先从规则文件中查找<factory>标签，找到需要加载的RuleFactory。通过反射的方式，创建该类型的实例（引擎默认的rule）

2.      在引擎的运行时，外部需要对规则文件中定义的rule有特殊的处理，必须在外部环境中构造BRERuleFactory对象，并以一个代理作为它的参数，在代理的方法中实现对rule的处理

讨论：是否还需要第三种方式，因为使用第二种方式扩展系统时，外部环境开发者不得不很了解目前使用的规则文件中到底使用了哪些扩展的rule，并为这些rule些处理方法。当我们修改了规则文件，并添加了一些扩展rule时，外部环境的开发者不得不修改他们的程序，以适应新的规则文件。

我们现在想要的是像使用默认的rule一样方式来使用扩展rule，这就需要我们用一种注册的方式，在引擎加载rule之前，将扩展的rule注册进系统。

所有的rule都必须通过引擎上下文（IBRERuleContext）的SetFactory方法注册进引擎上下文中

IBRERuleFactory中有ExecuteRule方法，这就是处理默认rule的方法

支持规则集的相关类型：IBRERuleFactory,BRERuleFactory(主要是为自定义的rule设计的，他的ExecuteRule中只是调用了代理)

在写代理方法的时候注意，引擎调用代理的时候，可以提供上下文和相关的参数，这是我们极其需要的

Flow Engine加载操作符
 

很简单，在BREImpl的init()方法中，用反射的方式从当前Assembly中查找所有实现IBREOperator接口的类型，创建实例，加入上下文中。

这里的操作符只是if语句中判断大小用的，而+，-，*，/，或其他数学函数，我认为可以作为默认的rule来对待

支持的相关类型：IBRERuleOperator,实现他的类其实就是实现一个compare的strategy

讨论：这一块是不是能满足需求

Flow Engine中提交数据对象
 

如前所述，数据对象在系统中是被当成result来处理的，封装他的BRERuleObject类继承于AbstractBRERuleResult，会被插入上下文的result集中。数据对象被封装到BRERuleObject的Result属性中。

具体的，在外部环境中，通过上下文的SetObject(id,object)，就可以将数据对象添加到上下文中了。

同样，获取数据对象的时候用上下文的GetObject(id)。

Flow Engine中命令引擎执行
 

在启动引擎之前，要注意必须执行BREImpl的Reset()方法，清空留在上下文中的上一次的Result集和CallStack清空，否则，可能会干扰本次的执行。这有一次表明了Flow Engine是一个对逻辑分支的瞬时遍历，他不能保存结果，也不能用于以往知识对执行实例有影响的系统中。

要执行引擎，只需调用BREImpl的process()方法，引擎就会根据规则文件中指定的逻辑来执行了。

更具体的，processxml()方法判断XPathNavigator当前节点的类型，跳转到特定的处理程序中。

如果当前节点有子节点，那么调用DoRecursion()来进行迭代。

执行的方式是先深的遍历。

Flow Engine中导出结果
 

很简单，通过上下文的GetResult(id)，就能导出运行的结果。Id与该条rule的id相同。

真正结果封装在AbstractBRERuleResult的result属性中

Flow Engine中的log和Exception处理
 

提供了丰富的向外部暴露内部运行情况的接口

还指定了log和exception的级别，用于向不同的终端暴露信息

内部使用DispatchLog(message,level),DispatchException(message,level)