重提一下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. 定义场景中的用户、业务逻辑和数据对象。

2. 定义对象的行为。

3. 定义对象的属性（attribute）或属性。

4. 定义对象之间的逻辑关系。

统一建模语言

统一建模语言(UML) 是阐述解决方案如何工作的工具。在图形化描述解决方案方面，它对于更完全分析解决方案非常有用。使用UML是一种容易的方法来画出组件、交互、关系和更多其他信息。通常，UML被用来方便的分析逻辑设计。

对象

当分析使用场景的时候，首要的任务就是确定其中的对象。一个对象通常是出现在场景中的一个业务实体或过程。例如，在下面的一段话中，粗体字就是对象:

用户(User)选择一个目录(Catalog)来浏览。分类 (Categories)和产品 (Products)被展现在已选的根目录(Catalog)中。用户(User)之后选择一个产品(Product)来查看它的细节或选择一个分类(Categories)来查看其中的产品(Product)和子分类。

在这个场景中，下列对象被使用到：

• User
• Catalog
• Categories
• Product
• Products

下面的UML图阐述了在本例中的对象。

在这个场景中有五个基础的对象；然而，为了实现场景的功能还可能需要一些附属的的对象，即使他们没有被特别的列入这个基础对象列表。你可以在检查动作的时候定义这些附属的对象。你首先要定义出动作，才能发现并定义这些附属的对象。

行为

在定义完明显的对象集合之后，下一步的工作就是定义他们各自的行为，以方法和服务的方式表现。

为了定义对象的行为，你必须首先估计场景中要做什么。例如，在下面的一段话中，动作备用粗体标识：

用户选择一个目录来浏览。分类和产品被展现在已选的根目录中。用户之后选择一个产品来查看它的细节或选择一个分类来查看其中的产品和子分类。

发生的第一件事是用户选择了一个目录。下面的UML图阐述了用户对象包含了一个选择目录的行为。

不能关联到明显对象的行为必须从场景中派生。如下面的情况，用户要选择一个目录，那么必须有一些机制使得一个目录可以从一个目录列表中被选中。你可以从逻辑上假定一个目录集合对象，他管理目录的集合。因此，你就可以在对象的列表中添加一个新的对象。

在定义完目录集合对象之后，你可以添加属于这个对象的第一个方法Select Catalog 。

之后，你需要继续估计场景中的每一句话，直到你定义出所的对象和相关的行为。

属性

定义完行为之后的下一步工作是定义对象的属性（attribute，或称为property）。属性是解决方案需要跟踪的元素。它们是数据保存和持续化的位置。

通过分析场景中的行为来定义属性（attribute），抽取出场景中需要跟踪或持续化的元素。例如，在前面一块中，场景指定用户需要查看产品。当产品被查看时，展现给用户的那些元素就是产品的属性（attribute）。例如，如果业务需要产品的描述和价格被展示给用户，这些元素就成为属性被添加到对象中去。

下面的UML图中阐述了包含Name属性的User对象。

关系

在定义完对象、行为和属性（attribute）之后，下一步是定义关系。关系是对象间的逻辑关联。

为了定义关系，需要分析对象间是如何交互的。例如，目录集合对象跟目录对象有一个关系，因为目录集合对象管理目录对象。

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"));

1介绍

缓存组件可以使开发者将本地的缓存机制加到应用程序中。它支持内存中缓存和可选的后端的存储（数据库方式和隔离存储方式）。缓存组件提供retrieve, add, and remove cached data等功能。过期和自我清除策略也是给组件的一部分。

缓存可以克服一些风险：

l         性能。采用一种更为密切的方式，为数据的消费者存储相关的数据；以避免重复性的数据创建、处理和传输。

l         可度量性。在缓存中存储信息可以节省资源，并随着应用程序的需求量增加，而增加可度量性

l         可用性。使用缓存，您的应用能够在网络的的延时、WEB服务和硬件的问题中减小损失。

常用场景