介绍

在实际使用quartz.net中，持久化能保证实例重启后job不丢失、 集群能均衡服务器压力和解决单点问题。

quartz.net在这两方面配置都比较简单。

持久化

quartz.net的持久化，是把job、trigger一些信息存储到数据库里面，以解决内存存储重启丢失。

下载sql脚本

           https://github.com/quartznet/quartznet/blob/master/database/tables/tables\_sqlServer.sql

创建个数据库，并执行脚本

  QRTZ_BLOB_TRIGGERS  以Blob 类型存储的触发器。

  QRTZ_CALENDARS   存放日历信息， quartz.net可以指定一个日历时间范围。

  QRTZ_CRON_TRIGGERS  cron表达式触发器。

  QRTZ_JOB_DETAILS      job详细信息。

  QRTZ_LOCKS       集群实现同步机制的行锁表

  QRTZ_SCHEDULER_STATE   实例信息，集群下多使用。

quartz.net 配置

//===持久化==== //存储类型
properties[“quartz.jobStore.type”] = “Quartz.Impl.AdoJobStore.JobStoreTX, Quartz”; //表明前缀
properties[“quartz.jobStore.tablePrefix”] = “QRTZ_“; //驱动类型
properties[“quartz.jobStore.driverDelegateType”] = “Quartz.Impl.AdoJobStore.SqlServerDelegate, Quartz”; //数据源名称
properties[“quartz.jobStore.dataSource”] = “myDS”; //连接字符串
properties[“quartz.dataSource.myDS.connectionString”] = @”Data Source=(local);Initial Catalog=JobScheduler;User ID=sa;Password=123465”; //sqlserver版本
properties[“quartz.dataSource.myDS.provider”] = “SqlServer-20”;

启动客户端

var properties = JobsManager.GetProperties(); var schedulerFactory = new StdSchedulerFactory(properties);
scheduler = schedulerFactory.GetScheduler();
scheduler.Start(); //var job = JobBuilder.Create() // .WithIdentity(“test”, “value”) // .Build(); //var trigger = (ICronTrigger) TriggerBuilder.Create() // .WithIdentity(“test”, “value”) // .WithCronSchedule(“0 0/5 * * * ?”) // .Build(); //scheduler.ScheduleJob(job, trigger);

补充

     1： 持久化后，job只有添加一次了(数据库已经有了)，所以不能再执行端写添加job的行为。这时候需要一个管理工具，动态添加操作。

     2： quartz.net 支持sql server、sqlite、mysql、oracle、mongodb(非官方版)。

部署图：

如图quartz.net 的集群模式是依赖数据库表的，所以要持久化配置。  集群节点之间是不通信的，这样分布式的架构，很方便进行水平扩展。

1: 除了线程池数量，instanceId可以不同外，各个节点的配置必须是一样的。

2：集群中节点的系统时间一致。  

3：多线程、集群中。quartz.net 利用数据库锁来保证job不会重复执行。

     源码在DBSemaphore.cs、UpdateLockRowSemaphore.cs、StdRowLockSemaphore.cs

4：集群化后，某节点失效后，剩余的节点能保证job继续执行下去。

实例配置后启动。

//cluster
properties[“quartz.jobStore.clustered”] = “true”;
properties[“quartz.scheduler.instanceId”] = “AUTO”;

简单管理界面：

介绍

前面介绍Quartz.Net的基本用法，但在实际应用中，往往有更多的特性需求，比如记录job执行的执行历史，发邮件等。

阅读目录

1. Quartz.Net插件
2. TriggerListener,JobListener
3. Cron表达式
4. Quartz.Net线程池
5. 总结

Quartz.Net插件

     Quartz.net 自身提供了一个插件接口(ISchedulerPlugin)用来增加附加功能，看下官方定义：

1

2

3

4

5

6

7

8

public interface ISchedulerPlugin

{

void Initialize(``string pluginName, IScheduler sched);

void Shutdown();

void Start();

}

　继承接口，实现自己的插件。

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

public class MyPlugin : ISchedulerPlugin

{

public void  Initialize(``string pluginName, IScheduler sched)

{

Console.WriteLine(``"实例化"``);

}

public  void Start()

{

Console.WriteLine(``"启动"``);

}

public  void Shutdown()

{

Console.WriteLine(``"关闭"``);

}

}

　　主函数里面配置要实现的插件，注释部分，一句话搞定。

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

static void Main(``string``[] args)

{

var properties = new NameValueCollection();

properties[``"quartz.plugin.MyPlugin.type"``] = "QuartzDemo3.MyPlugin,QuartzDemo3"``;

var schedulerFactory = new StdSchedulerFactory(properties);

var scheduler = schedulerFactory.GetScheduler();

var job = JobBuilder.Create<HelloJob>()

.WithIdentity(``"myJob"``, "group1"``)

.Build();

var trigger = TriggerBuilder.Create()

.WithIdentity(``"mytrigger"``, "group1"``)

.WithCronSchedule(``"/2 * * ? * *"``)

.Build();

scheduler.ScheduleJob(job, trigger);

scheduler.Start();

Thread.Sleep(6000);

scheduler.Shutdown(``true``);

Console.ReadLine();

}

运行结果如下：

  — Quartz.Net进阶/172151135196757.png)

TriggerListener，JobListener

这2个是对触发器和job本身的行为监听器，这样更好方便跟踪Job的状态及运行情况。  

ITriggerListener是官方定义的接口，这里我们直接继承实现。 

public class MyTriggerListener : ITriggerListener
{ private string name; public void TriggerComplete(ITrigger trigger, IJobExecutionContext context, SchedulerInstruction triggerInstructionCode)
{
Console.WriteLine(“job完成时调用”);
} public void TriggerFired(ITrigger trigger, IJobExecutionContext context)
{
Console.WriteLine(“job执行时调用”);
} public void TriggerMisfired(ITrigger trigger)
{
Console.WriteLine(“错过触发时调用(例：线程不够用的情况下)”);
} public bool VetoJobExecution(ITrigger trigger, IJobExecutionContext context)
{ //Trigger触发后，job执行时调用本方法。true即否决，job后面不执行。
return false;
} public string Name { get { return name; } set { name = value; } }
}

主函数添加：

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

scheduler.ListenerManager.AddTriggerListener(myJobListener, KeyMatcher<TriggerKey>.KeyEquals(``new TriggerKey(``"mytrigger"``, "group1"``)));

////添加监听器到指定分类的所有监听器。

////添加监听器到指定分类的所有监听器。

////添加监听器到指定的2个分组。

////添加监听器到所有的触发器上。

scheduler.Start();

JobListener同理，这里不多做描述。

Cron表达式

quartz中的cron表达式和Linux下的很类似，比如 “/5 * * ? * * *“ 这样的7位表达式，最后一位年非必选。

表达式从左到右，依此是秒、分、时、月第几天、月、周几、年。下面表格是要遵守的规范：

字段名

允许的值

允许的特殊字符

Seconds

0-59

, - * /

Minutes

0-59

, - * /

Hours

0-23

, - * /

Day of month

1-31

, - * ? / L W

Month

1-12 or JAN-DEC

, - * /

Day of week

1-7 or SUN-SAT

, - * ? / L #

Year

空, 1970-2099

, - * /

特殊字符

解释

,

或的意思。例：分钟位 5,10  即第5分钟或10分都触发。 

/

a/b。 a：代表起始时间，b频率时间。 例； 分钟位  3/5，  从第三分钟开始，每5分钟执行一次。

*

频率。 即每一次波动。    例；分钟位 *  即表示每分钟 

-

区间。  例： 分钟位   5-10 即5到10分期间。 

?

任意值 。   即每一次波动。只能用在DayofMonth和DayofWeek，二者冲突。指定一个另一个一个要用?

L

表示最后。 只能用在DayofMonth和DayofWeek，4L即最后一个星期三

W

工作日。  表示最后。 只能用在DayofWeek

4#2。 只能用DayofMonth。 某月的第二个星期三  

实例介绍

”0 0 10,14,16 * * ?”    每天10点，14点，16点 触发。

“0 0/5 14,18 * * ?”    每天14点或18点中，每5分钟触发 。

“0 4/15 14-18 * * ?”       每天14点到18点期间,  从第四分钟触发，每15分钟一次。

“0 15 10 ? * 6L”        每月的最后一个星期五上午10:15触发。

Quartz.Net线程池

线程池数量设置：

properties[“quartz.threadPool.threadCount”] = “5”;

这个线程池的设置，是指同时间，调度器能执行Job的最大数量。

quartz是用每个线程跑一个job。上面的设置可以解释是job并发时能执行5个job，剩下的job如果触发时间恰好到了，当前job会进入暂停状态，直到有可用的线程。

如果在指定的时间范围依旧没有可用线程，会触发misfired时间。

quartz 提供了IThreadPool接口，也可以用自定义线程池来实现。

配置如下：

properties[“quartz.threadPool.type”] = “Quartz.Simpl.SimpleThreadPool, Quartz”;

一般来说作业调度很少并发触发大量job，如果有上百个JOB，可在服务器承受范围内适量增加线程数量。     

总结

官方有LoggingTriggerHistoryPlugin，LoggingJobHistoryPlugin  已实现的，触发器和job历史记录的插件。

Quartz.Plugin 命名空间下有官方实现的其他一些插件，也可以自己增加扩展。

quartz中监听器还有SchedulerListener，使用方法基本一样。 

本文基于自用经验和官方文档代码来写的，部分是直接翻译的。 

Quartz.Net官方教程http://www.quartz-scheduler.net/documentation/quartz-2.x/tutorial/index.html

介绍

上篇已经了解Quartz.NET的基本使用方法了。但如果想方便的知道某个作业执行情况，需要暂停，启动等操作行为，这时候就需要个Job管理的界面。

本文介绍Quartz.NET如何进行远程job管理，如图:

-CrystalQuartz远程管理/011755051751192.png)

实战

一：作业服务端

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

static void Main(``string``[] args)

{

var properties = new NameValueCollection();

properties[``"quartz.scheduler.instanceName"``] = "RemoteServerSchedulerClient"``;

properties[``"quartz.threadPool.type"``] = "Quartz.Simpl.SimpleThreadPool, Quartz"``;

properties[``"quartz.threadPool.threadCount"``] = "5"``;

properties[``"quartz.threadPool.threadPriority"``] = "Normal"``;

properties[``"quartz.scheduler.exporter.type"``] = "Quartz.Simpl.RemotingSchedulerExporter, Quartz"``;

properties[``"quartz.scheduler.exporter.port"``] = "556"``;

properties[``"quartz.scheduler.exporter.bindName"``] = "QuartzScheduler"``;

properties[``"quartz.scheduler.exporter.channelType"``] = "tcp"``;

var schedulerFactory = new StdSchedulerFactory(properties);

var scheduler = schedulerFactory.GetScheduler();

var job = JobBuilder.Create<PrintMessageJob>()

.WithIdentity(``"myJob"``, "group1"``)

.Build();

var trigger = TriggerBuilder.Create()

.WithIdentity(``"myJobTrigger"``, "group1"``)

.StartNow()

.WithCronSchedule(``"/10 * * ? * *"``)

.Build();

scheduler.ScheduleJob(job, trigger);

scheduler.Start();

}

1

2

3

4

5

6

7

public class PrintMessageJob : IJob

{

public void Execute(IJobExecutionContext context)

{

Console.WriteLine(``"Hello!"``);

}

}

启动如下

-CrystalQuartz远程管理/011801015192327.png)

二：作业远程管理端，无需写任何代码，引用官方程序集，嵌入到已有的web网站。 

      PM> Install-Package CrystalQuartz.Remote

      Webconfig 需要配置的地方

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

<configuration>

<crystalQuartz>

<provider>

<add property=``"Type" value=``"CrystalQuartz.Core.SchedulerProviders.RemoteSchedulerProvider, CrystalQuartz.Core" />

<add property=``"SchedulerHost" value=``"tcp://127.0.0.1:556/QuartzScheduler" /> <!--TCP监听的地址-->

</provider>

</crystalQuartz>

<system.webServer>

<!-- Handler拦截处理了，输出作业监控页面-->

<handlers>

<add name=``"CrystalQuartzPanel" verb=``"*" path=``"CrystalQuartzPanel.axd" type=``"CrystalQuartz.Web.PagesHandler, CrystalQuartz.Web" />

</handlers>

</system.webServer>

</configuration>

　Web管理界面

-CrystalQuartz远程管理/011811269404890.png)

其他

CrystalQuartz 提供基础功能，可以继续在此基础上进行二次开发，另外推荐使用Window服务寄宿，比较方法。

参考资源

张善友   　　　　　　　　    http://www.cnblogs.com/shanyou/archive/2012/01/15/2323011.html

CrystalQuartz开源的地址 　　https://github.com/guryanovev/CrystalQuartz

背景

很多时候，项目需要在不同时刻，执行一个或很多个不同的作业。

Windows执行计划这时并不能很好的满足需求了，迫切需要一个更为强大，方便管理，集群部署的作业调度框架。

介绍

Quartz 一个开源的作业调度框架，OpenSymphony的开源项目。Quartz.Net 是Quartz的C#移植版本。

它一些很好的特性：

1：支持集群，作业分组，作业远程管理。 

2：自定义精细的时间触发器，使用简单，作业和触发分离。

3：数据库支持，可以寄宿Windows服务，WebSite，winform等。

实战

Quartz框架的一些基础概念解释：

 　　Scheduler     作业调度器。

 　　IJob             作业接口，继承并实现Execute， 编写执行的具体作业逻辑。

　　JobBuilder       根据设置，生成一个详细作业信息(JobDetail)。

　　TriggerBuilder   根据规则，生产对应的Trigger

Nuget安装 

PM> Install-Package Quartz

下面是简单使用例子，附带详细的注释：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

static void Main(string[] args)
{
 IScheduler scheduler = StdSchedulerFactory.GetDefaultScheduler();
 scheduler.Start(); 

 IJobDetail job1 = JobBuilder.Create<HelloJob>()
 .WithIdentity("作业名称", "作业组")
 .Build();

 ITrigger trigger1 = TriggerBuilder.Create()
 .WithIdentity("触发器名称", "触发器组")
 .StartNow() 
 .WithSimpleSchedule(x => x 
 .WithIntervalInSeconds(5)
 .RepeatForever()) 
 .Build();

 scheduler.ScheduleJob(job1, trigger1); 

 IJobDetail job2= JobBuilder.Create<DumbJob>()
 .WithIdentity("myJob", "group1")
 .UsingJobData("jobSays", "Hello World!")
 .Build();

 ITrigger trigger2 = TriggerBuilder.Create()
 .WithIdentity("mytrigger", "group1")
 .StartNow()
 .WithCronSchedule("/5 * * ? * *") 
 .Build();
 scheduler.ScheduleJob(job2, trigger2); 
}

声明要执行的作业，HelloJob：

1
2
3
4
5
6
7
8
9
10
11
12

/// <summary>
/// 作业
/// </summary>
public class HelloJob : IJob
{
 public void Execute(IJobExecutionContext context)
 {
 Console.WriteLine("作业执行!");
 }
}

声明要执行的作业，DumbJob：

public class DumbJob : IJob

{

/// <summary>

///  context 可以获取当前Job的各种状态。

/// </summary>

/// <param name="context"></param>

public void Execute(IJobExecutionContext context)

{

JobDataMap dataMap = context.JobDetail.JobDataMap;

string content = dataMap.GetString(``"jobSays"``);

Console.WriteLine(``"作业执行，jobSays:" + content);

}

}

其WithCronSchedule(“”) 拥有强大的Cron时间表达式，正常情况下_WithSimpleSchedule(x)_ 已经满足大部分对日期设置的要求了。

Quartz.Net官方2.X教程  http://www.quartz-scheduler.net/documentation/quartz-2.x/tutorial/index.html

Quartz.Net开源地址   https://github.com/quartznet/quartznet

**
三、插件系统**

   上回书说到SharpDevelop入口Main函数的结构，ServiceManager.Service在InitializeServicesSubsystem方法中首次调用了AddInTreeSingleton的AddInTree实例，AddInTree在这里进行了初始化。本回进入AddInTree着重讲述SharpDevelop的插件系统。在叙述的时候为了方便起见，对于“插件”和插件具体的“功能模块”这两个词不会特别的区分，各位看官可以从上下文分辨具体的含义（而事实上，SharpDevelop中的“插件”是指.addin配置文件，每一个“插件”都可能会包含多个“功能模块”）。

1、插件的配置
   既然说到插件系统，那么我们先来看一看SharpDevelop插件系统的组织形式。
   很多时候，同一个事物从不同的角度来看会得出不一样的结论，SharpDevelop的插件系统也是如此。在看SharpDevelop的代码以前，按照我对插件的理解，我认为所谓的“插件”就是代表一个功能模块，插件的配置就是描述该插件并指定如何把这个插件挂到系统中。SharpDevelop中有插件树的思想，也就是每一个插件在系统中都有一个扩展点的路径。那么按照我最初对插件的理解，编写插件需要做的就是：
   A、根据插件接口编写功能模块实现一个Command类
   B、编写一个配置文件，指定Command类的扩展点(Extension)路径，挂到插件树中

   之后按照这样的理解，我编写了一个察看插件树的插件AddinTreeView，打算挂到SharpDevelop中去。根据SharpDevelop对插件的定义，我把具体插件的AddinTreeViewCommand实现了之后，编写了一个配置文件AddinTreeView.addin如下：

   在配置文件中，Runtime节指定了插件功能模块所在的库文件Addins.dll的具体路径，在Extension节中指定了扩展点路径/SharpDevelop/Workbench/MainMenu/Tools（我是打算把它挂到主菜单的工具菜单下），然后在Extension内指定了它的Codon为 MenuItem以及具体的ID、标签、Command类名。这样做，SharpDevelop运行的很不错，我的插件出现在了Tools菜单下。之后，我又编写了一个SharpDevelop的资源管理器（ResourceEditor）的插件类ResourceEditor.dll并把它挂到Tool菜单下。同样的，我也写了一个ResourceEditor.addin文件来对应。系统工作的很正常。

   如果我们对于每一个插件都编写这样的一个配置文件，那么插件的库文件(.dll)、插件配置文件(.addin)是一一对应的。不过这样就带来了一个小小的问题，在这样的一个以插件为基础的系统中，每一个菜单、工具栏按钮、窗体、面板都是一个插件，那么我们需要为每一个插件编写配置文件，这样就会有很多个配置文件（似乎有点太多了，不是很好管理）。SharpDevelop也想到了这个问题，于是它允许我们把多个插件的配置合并在一个插件的配置文件中。因此，我把我的两个插件库文件合并到一个Addins工程内生成了Addins.dll，又重新编写了我的插件配置文件MyAddins.addin如下：

   这样，我把两个插件的功能模块使用一个插件配置文件来进行配置。同样的，我也可以把几十个功能模块合并到一个插件配置文件中。SharpDevelop把这个插件配置文件称为“Addin(插件)”，而把具体的功能模块封装为Codon，使用Command类来包装具体的功能。SharpDevelop本身的核心配置SharpDevelopCore.addin里面就包含了所有的基本菜单、工具栏、PAD的插件配置。
我们回过头来看一下，现在我们有了两颗树。首先，插件树本身是一个树形的结构，这个树是根据系统所有插件的各个Codon的扩展点路径构造的，表示了各个Codon在插件树中的位置，各位看官可以通过我写的这个小小的AddinTreeView来看看SharpDevelop中实际的结构。其次，插件的配置文件本身也具有了一个树形的结构，这个树结构的根节点是系统的各个插件配置文件，其下是根据这个配置文件中的Extension节点的来构成的，描述了每个Extension节点下具有的Codon。我们可以通过SharpDevelop的Tools菜单下的AddinScout来看看这个树的结构。
我为了试验，把SharpDevelop的插件精简了很多，构成了一个简单的小插件系统。下面是这个精简系统的两个树的截图。各位看官可以通过这两副图理解一下插件树和插件配置文件的关系（只是看同样问题的两个角度，一个是Codon的ExtensionPath，一个是配置文件的内容）。


总结一下SharpDevelop插件的配置文件格式。首先是 节点，需要指定AddIn的名称、作者之类的属性。其次，在AddIn节点下的节点内，使用<Import …>来指定本插件配置中Codon所在的库文件。如果分布在多个库文件中，可以一一指明。然后，编写具体功能模块的配置。每个功能模块的配置都以扩展点开始，指定了路径(Path)属性之后，在这个节点内配置在这个扩展点下具体的Codon。每个Codon根据具体不同的实现有不同的属性。各位看官可以研究一下SharpDevelop的核心配置文件SharpDevelopCore.addin的写法，相信很容易理解的。

2、插件系统的核心AddIn和AddInTree
   前文讲到，在SharpDevelop的Main函数中，ServiceManager.Service在InitializeServicesSubsystem方法中首次调用了AddInTreeSingleton的AddInTree实例，AddinTree在这个时候进行了初始化。现在我们就来看看AddInTreeSingleton.AddInTree到底做了些什么事情，它定义在/src/Main/Core/AddIns/AddInTreeSingleton.cs文件中。

   AddInTreeSingleton是插件树的一个Singleton（具体的可以去看《设计模式》了），AddInTreeSingleton.AddInTree是一个属性，返回一个IAddinTree接口。这里我注意到一点，AddInTreeSingleton是从DefaultAddInTree继承下来的。既然它是一个单件模式，包含的方法全部都是静态方法，没有实例化的必要，而且外部是通过AddInTree属性来访问插件树，为什么要从DefaultAddInTree继承呢？这好像没有什么必要。这也许是重构过程中被遗漏的一个小问题吧。

   我们先来看看IAddinTree接口的内容，它定义了这样的几个内容：
      A、属性ConditionFactory ConditionFactory　返回一个构造条件的工厂类，这里的条件是指插件配置中的条件，我们以后再详细说明。
      B、属性CodonFactory CodonFactory　返回一个构造Codon的工厂类。
      C、属性AddInCollection AddIns 返回插件树的根节点Addin（插件）集合。
      D、方法IAddInTreeNode GetTreeNode(string path) 根据扩展点路径（path）返回对应的树节点
      E、方法void InsertAddIn(AddIn addIn) 根据AddIn中的扩展点路径添加一个插件到树中
      F、方法void RemoveAddIn(AddIn addIn) 删除一个插件
      G、方法Assembly LoadAssembly(string assemblyFile)  读入插件中Runtime节的Import指定的Assembly，并构造相应的CodonFactory和CodonFactory类。

   AddInTreeSingleton在首次调用AddInTree的时候会调用CreateAddInTree方法来进行初始化。CreateAddInTree方法是这样实现的：

addInTree  = new  DefaultAddInTree();

      初始化插件树为DefaultAddInTree的实例，这里我感受到了一点重构的痕迹。首先，DefaultAddInTree从名称上看是默认的插件树（既然是默认，那么换句话说还可以有其他的插件树）。但是SharpDevelop并没有给外部提供使用自定义插件树的接口（除非我们修改这里的代码），也就是说这个名称并不像它本身所暗示的那样。其次，按照Singleton通常的写法以及前面提到AddInTreeSingleton是从DefaultAddInTree继承下来的疑问，我猜想DefaultAddinTree的内容本来是在AddinTreeSingleton里面实现的，后来也许为了代码的条理性，把实现IAddinTree内容的代码剥离了出去，形成了DefaultAddinTree类。至于继承DefaultAddInTree的问题，也许这里本来是一个AddInTree的基类。这是题外话，也未加证实，各位看官可以不必放在心上（有兴趣的可以去找找以前SharpDevelop的老版本的代码来看看）。
这里有两个察看代码的线路，一个是DefaultAddInTree的构造函数的代码，在这个构造函数中构造了Codon和Condtion的工厂类。另外一个是CreateAddInTree后面的代码，搜索插件文件，并根据插件文件进行AddIn的构造。各位看官可以选择走分支线路，也可以选择先看主线（不过这样你会漏掉不少内容）。

2.1 支线 （DefaultAddInTree的构造函数）
   我们把CreateAddInTree的代码中断一下压栈先，跳到DefaultAddInTree的构造函数中去看一看。DefaultAddInTree定义在/src/Main/Core/AddIns/DefaultAddInTree.cs文件中。在DefaultAddInTree的构造函数中，注意到它具有一个修饰符internal，也就是说这个类只允许Core这个程序集中的类对DefaultAddInTree进行实例化（真狠啊）。构造函数中的代码只有一句：

 LoadCodonsAndConditions(Assembly.GetExecutingAssembly());

   虽然只有一行代码，不过这里所包含的内容却很精巧，是全局的关键，要讲清楚我可有得写了。首先，通过全局的Assembly对象取得入口程序的Assembly，传入LoadCodonsAndConditions方法中。在该方法中，枚举传入的Assembly中的所有数据类型。如果不是抽象的，并且是AbstractCodon的子类，并且具有对应的CodonNameAttribute属性信息，那么就根据这个类的名称建立一个对应的CodonBuilder并它加入CodonFactory中（之后对Condition也进行了同样的操作，我们专注来看Codon部分，Condition跟Codon基本上是一样的）。
   这里的CodonFactory类和CodonBuilder类构成了SharpDevelop插件系统灵活的基础，各位看官可要看仔细了。
   我们以实例来演示，以前文我编写的AddinTreeViewCommand为例。在入口的Assembly中会搜索到MenuItemCodon，它是AbstractCodon的一个子类、包装MenuItem(菜单项)Command（命令）的Codon。符合条件，执行

codonFactory.AddCodonBuilder( new  CodonBuilder(type.FullName, assembly));

   首先根据类名MenuItemCodon和assembly 构造CodonBuilder。CodonBuilder定义在/src/Main/Core/AddIns/Codons/CodonBuilder.cs文件中。在CodonBuilder的构造函数中根据MenuItemCodon的CodonNameAttribute属性信息取得该Codon的名称MenuItem。CodonNameAttribute描述了Codon的名称，这个MenuItem也就是在.addin配置文件中对应的标签，后文会看到它的重要用途。在CodonBuilder中除了包含了该Codon的ClassName（类名）和CodonName属性之外，就只有一个方法BuildCodon了。

   很明显，BuildCodon根据构造函数中传入的assembly和类型的ClassName，建立了具体的Codon的实例，并和具体的AddIn关联起来。
   之后，codonFactory调用AddCodonBuilder方法把这个CodonBuilder加入它的Builder集合中。我们向上一层，看看codonFactory如何使用这个CodonBuilder。
   在文件/src/Main/Core/AddIns/Codons/CodonFactory.cs中，codonFactory只有两个方法。AddCodonBuilder方法把CodonBuilder加入一个以CodonName为索引的Hashtable中。另外一个方法很重要：

   在这里，addin是这个配置文件的描述（也就是插件），而这个XmlNode类型的CodonNode是什么东西？
   还记得配置文件中在标签下的、、之类的标签吗？我曾经说过，这些就是Codon的描述，现在我们来看看到底是不是如此。以前文的AddinTreeView配置为例：

   SharpDevelop在读入插件配置文件的标签之后，就把它的ChildNodes（XmlElement的属性）依次传入CodonFactory的CreateCodon方法中。这里它的ChildNodes[0]就是这里的节点，也就是codonNode参数了。这个XML节点的Name是MenuItem，因此CreateCodon的第一行

CodonBuilder builder  =  codonHashtable[codonNode.Name]  as  CodonBuilder;

   根据节点的名称(MenuItem)查找对应的CodonBuilder。记得前面的CodonBuilder根据CodonNameAttribute取得了MenuItemCodon的CodonName吗？就是这个MenuItem了。CodonFactory找到了对应的MenuItemCodon的CodonBuilder（这个是在DefaultAddInTree的构造函数中调用LoadCodonsAndConditions方法建立并加入CodonFactory中的，还记得么？），之后使用这个CodonBuilder建立了对应的Codon，并把它返回给调用者。
   就这样，通过CodonNameAttribute，SharpDevelop把addin配置文件的节点、CodonBulder、MenuItemCodon三部分串起来形成了一个构造Codon的路线。

   我们回过头来整理一下思路，SharpDevelop进行了下面这样几步工作：
      A、建立各个Codon，使用CodonNameAttribute指明它在配置节点中的名称
      B、DefaultAddInTree的构造函数中调用LoadCodonsAndConditions方法，搜索所有的Codon，根据Codon的CodonNameAttribute建立对应的CodonBuilder加入CodonFactory中。
      C、读取配置文件，在标签下遍历所有的节点，根据节点的Name使用CodonFactory建立对应的Codon。
   其中，Codon的CodonNameAttribute、CodonBuilder的CodonName以及标签下XML节点的Name是一致的。对于Condition（条件）的处理也是一样。
   抱歉，我上网不是很方便也不太会在Blog里面贴图（都是为了省事的借口^o^），否则也许更好理解这里的脉络关系。

   好了，看到这里，我们看看SharpDevelop中插件的灵活性是如何体现的。首先，addin配置中的Extension节点下的Codon节点名称并没有在代码中和具体的Codon类联系起来，而是通过CodonNameAttribute跟Codon联系起来。这样做的好处是，SharpDevelop的Codon和XML的标签一样具有无限的扩展能力。假设我们要自己定义一个Codon类SplashFormCodon作用是指定某个窗体作为系统启动时的封面窗体。要做的工作很简单：首先，在SplashFormCodon中使用CodonNameAttribute指定CodonName为Splash，并且在SplashFormCodon中定义自己需要的属性。然后，在addin配置文件使用标签这样写：

   是不是很简单？另外，对于Condition（条件）的处理也是一样，也就是说我们也可以使用类似的方法灵活的加入自己定义的条件。

   这里我有个小小的疑问：不知道我对于设计模式的理解是不是有点小问题，我感觉CodonBuilder类的实现似乎并不如它的类名所暗示的是《设计模式》中的Builder模式，反而似乎应该是Proxy模式，因此我觉得改叫做CodonProxy是不是比较容易理解？各位看官觉得呢？
   另外，虽然稍微麻烦了一小点，不过我觉得配置如果这样写会让我们比较容易和代码中具体的类关联起来:

2.2 主线 (AddInTreeSingleton. CreateAddInTree)
   啊～我写的有点累了。不过还是让我们继续AddInTreeSingleton中CreateAddInTree的代码。
   在建立了DefaultAddInTree的实例后，AddInTreeSingleton在插件目录中搜索后缀为.addin的文件。还记得在SharpDevelop的Main函数中曾经调用过AddInTreeSingleton. SetAddInDirectories吗，就是搜索这个传入的目录。看来SharpDevelop把在插件目录中所有后缀为.addin的文件都看做是插件了。

FileUtilityService fileUtilityService  =  (FileUtilityService)ServiceManager.Services.GetService( typeof (FileUtilityService));

   先学习一下如何从ServiceManager取得所需要的服务，在SharpDevelop中要取得一个服务全部都是通过这种方式取得的。调用GetService传入要获取的服务类的类型作为参数，返回一个IService接口，之后转换成需要的服务。

   搜索插件目录找到一个addin文件后，调用InsertAddIns把这个addin文件中的配置加入到目录树中。

   InsertAddIns建立一个对应的AddIn（插件），调用AddInTree的InsertAddIn方法把它挂到插件树中。在这里有一个小小的处理，由于是通过Assembly查找和插件配置中Codon的标签对应的类，而Codon类所在的Assembly是通过Import标签导入的。因此在查找配置中某个Codon标签对应的Codon类的时候，也许Codon类所在的文件是在其他的addin文件中Import的。这个时候在前面支线中讲到CodonFactory中查找CodonBuilder会失败，因此必须等到Codon类所在的addin处理之后才能正确的找到CodonBuilder。这是一个依赖关系的处理问题。
   SharpDevelop在这里处理的比较简单，调用InsertAddIns方法的时候，凡是出现CodonNotFoundException的时候，都加入一个retryList列表中返回。在CreateAddinTree处理完所有的addin文件之后，再重新循环尝试处理retryList列表中的addin。如果某次循环中再也无法成功的加入retryList中的addin，那么才提示失败错误。

   我们回头来看看对AddIn的处理。

**2.2.1  addIn.Initialize （AddIn的初始化）
**   建立了AddIn的实例后，调用Initialize 方法进行初始化。AddIn是对一个.addin文件的封装，定义在/src/Main/Core/AddIns/AddIn.cs文件中。其中包含了.addin文件的根元素的描述，包括名称、作者、版权之类的属性。在节点下包括两种节点：一个是节点，包含了指定要导入的Assembly；另外一个是节点，指定Codon的扩展点。在AddIn.Initialize方法中，使用XmlDocument对象来读取对应的addin文件。首先读取name、author 、copyright之类的基本属性，之后遍历所有的ChildNodes（子节点）。

   如果子节点是Runtime节点，则调用AddRuntimeLibraries方法。

   通过AddInTreeSingleton.AddInTree.LoadAssembly方法把Assembly中所有的Codon和Condition的子类加入对应Factory类中（调用了LoadCodonsAndConditions方法，我们在DefaultAddInTree的构造函数中见过了），并且把该文件和对应的Assembly保存到RuntimeLibraries列表中。

   如果子节点是Extension节点，则调用AddExtensions方法。

   根据这个扩展点的XML描述建立Extension对象加入到AddIn的Extensions列表中，并通过AddCodonsToExtension方法把其中包括的Codon加入到建立的Extension对象中。Extension对象是AddIn的一个内嵌类，其中一个重要的属性就是CodonCollection这个列表。AddCodonsToExtension就是把在配置中出现的Codon都加入到这个列表中保存。

   来看看AddCodonsToExtension方法。在代码中我略过了对Condition（条件）的处理的分析和一些无关紧要的部分，我们把注意力集中在插件的处理。首先是一个 foreach (object o in el.ChildNodes) 遍历下所有的子节点，对于每个子节点的处理如下：

   我们看到了一个期待已久的调用

AddInTreeSingleton.AddInTree.CodonFactory.CreateCodon( this , curEl);

   经过了上文支线2.1代码中的铺垫，SharpDevelop使用建立好的CodonFactory，调用CreateCodon方法根据下的节点构造出实际的Codon对象，一切尽在不言中了吧。
   e.CodonCollection.Add(codon);把构造出来的Codon对象加入到Extension对象的CodonCollection列表中。
   之后，在形如菜单的这种允许无限嵌套的结构中，SharpDevelop对此进行了处理。如果该节点有嵌套的子节点，那么构造一个新的Extension对象，递归调用AddCodonsToExtension添加到这个Extension对象中。注意一点，这个新构造的Extension对象并不是分开保存在Codon中，而是直接保存在AddIn的扩展点列表中。这样是为了方便查找，毕竟保存在具体的Codon中也没有什么用处，我们可以通过Extension对象的Path属性得知它在插件树中的具体位置。

2.2.2 addInTree.InsertAddIn（把AddIn添加到AddInTree中）
   对AddIn的构造完成之后，需要把AddIn的实例对象添加AddInTree中管理。

   在DefaultAddInTree中，保存了两课树。一个是根据插件文件的结构形成的树，每个插件文件作为根节点，往下依次是Extension、Codon节点。addIns.Add(addIn);就是把插件加入到这个树结构中。另外一个树是根据Extension的Path＋Codon的ID作为路径构造出来的，每一个树节点是一个AddInTreeNode类，包含了在这个路径上的Codon对象。嵌套在这个节点中的Codon在通过它子节点来访问。在DefaultAddInTree中可以通过GetTreeNode来指定一个路径获得插件树上某一个节点的内容。
   AddExtensions方法很简单，遍历Extension中所有的Codon，把Extension的Path＋Codon的ID作为路径，创建这个路径上的所有节点，并把Codon连接到这个AddInTreeNode上。由于Codon的ID是全局唯一的，因此每一个AddInTreeNode都具有一个唯一的Codon。

3、最后一公里（Codon和Command的关联）
   在插件树的讨论中，我们依次把AddIn－Extension－Codon的配置和他们对应的类关联了起来。不过我们一直没有涉及到Codon和它包含的Command是如何关联的。由于这个关联调用是在插件树外部的（记得在讲述SharpDevelop程序入口Main函数中，提到ServiceManager的方法InitializeServicesSubsystem么？AddServices((IService[])AddInTreeSingleton.AddInTree.GetTreeNode(servicesPath).BuildChildItems(this).ToArray(typeof(IService))); 这里就调用了BuildChildItems），因此单独在这里说明。实现这个关联的就是AddInTreeNode的BuildChildItems和BuildChildItem方法以及Codon的BuildItem方法。
   BuildChildItem方法和BuildChildItems方法仅有一字之差，BuildChildItem是根据指定的Codon的ID在所属AddInTreeNode的子节点下查找包含该Codon的节点并调用该Codon的BuildItem方法；而BuildChildItems则是首先遍历所属AddInTreeNode的所有子节点，依次调用各个子节点的Codon的BuildItem方法，之后再调用所属AddInTreeNode的Codon的BuildItem方法（也就是一个树的后根遍历）。
   重点在Codon的BuildItem方法。在AbstractCodon中，这个方法是一个抽象方法，SharpDevelop的代码注释中并没有明确说清楚这个方法是做什么用的。但是我们可以找一个Codon的实例来看看。例如ClassCodon的BuildItem：

   调用AddIn的CreateObject，传入Codon的Class（类名）作为参数，建立这个类的实例。例如这个配置

   而Codon的中的Class（类名）属性就是ICSharpCode.SharpDevelop.Commands.InitializeWorkbenchCommand。也就是说，Codon的Class指的是实现具体功能模块的Command类的名称。在读取addin配置中的节的时候，AddInTree把Assembly保存到了RuntimeLibraries中，因此CreateObject方法可以通过它们来查找并建立类的实例。
   各位看官可以再看看MenuItemCodon的实现，同样是建立了对应的SdMenuCommand。
   这样，SharpDevelop本身的插件结构可以和具体的对象建立分离开来，实际的对象建立是在各个Codon的BuildItem中进行的。因此我们可以发现在SharpDevelop整个是基础插件系统部分没有任何GUI的操作，实现了很好的解耦效果。

4、问题
   好了，本文对插件树构造的分析到此告一段落。我提一个小小的问题给各位看官思考：在构造插件树的过程中，如果Codon的某一个节点路径不存在（也就是说它的依赖项不存在），那么SharpDevelop会提示失败并且终止程序运行。可是实际上可能因为部署的原因或者权限的原因，某些Codon的失败并不会影响整个系统的使用，例如试用版本仅仅提供部分插件给客户使用，而并不希望系统因此而终止运行。那么就存在一个Codon依赖项失败而允许继续运行的问题。另外，我希望各个插件不在系统启动的时候全部调入系统，而是在运行期实际调用的时候才调入系统，也就是一个缓存机制，这样就可以实现系统插件的热部署。如何修改SharpDevelop的插件系统来实现这两个功能呢？

   下一回书，应某位网友的要求，分析一下SharpDevelop中的服务。

石榴刺猬 2004-10-07 20:10:00

版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。

二、主程序

    在大学课程里面，我对于模拟电路总是搞不清楚，直到现在也是这样。我总觉得电路图很奇怪，总会问“这部分电路是做什么用的”、“为什么会有这样的效果”。在我的脑海里面，每部分的电路都应该有一定的用处，可是我总是看不明白。我妈妈说，我的思路被软件所固化的太久了，看电路图不应该总是一个个模块的看，正确的方法应该是从电源的一极顺着电路看，一直看到电源的另一极。我现在仍然不懂看电路图，可是以我看代码的经验来说，我觉得分析源代码按照这样的思路来看会比较容易把脉络理清楚。
     在SharpDevelop的代码中，由于很多的接口和插件的原因，很多代码在看到某个地方会突然失去函数/方法调用的线索。例如看某个函数的实现的时候会跳到一个接口里面去，那是因为这部分功能在运行期才会给一个实现了这个接口的对象来进行具体的执行。从这个角度来说，设计模式也给我们研究代码稍微带来了一点小小的难度。在看Linux下源代码的时候也经常遇到这种问题，在这个时候寻找代码线索比较好的方法是用一个文本搜索工具来搜索相关的关键字。在Linux下我经常会用grep，Windows下面类似UltraEdit的“批量文件查找”功能会很好用（或者“Search And Replace”之类的工具）。这个是我读代码的一点小小的经验，如果你知道有更好的方法，请告诉我让我也学习一下 ? 。
     我不想大段大段的贴代码出来占地方（空间、带宽，还有各位看官的注意力），在需要的地方我会贴上主要的代码，因此最好能够找代码来对应着看。把代码包解压缩，我把它解到了“F:/SharpDevelop”（如果没有说明，下文都是以此为代码的根目录了）。由于SharpDevelop本身对于察看代码不是很方便，没有“转到定义”之类的功能，因此我建议你把它的代码转成VS的工程来看。不过很可惜，SharpDevelop的工程导出功能现在有问题，如果导出/src/SharpDevelop.cmbx 这个总的复合工程的话会失败（我记得RC1版本是可以成功的，不知道为什么后来的版本反而会出问题），所以只能一个一个工程的导出。
     好了，让我们来看SharpDevelop的代码吧。
1、起点
    在主程序的起点在/src/Main/StartUp/SharpDevelopMain.cs，找到Main函数这就是整个程序的起点了。开始的部分是显示封面窗体并加上命令行控制，其中SplashScreenForm 定义在/src/Main/Base/Gui/Dialogs/SplashScreen.cs文件中，这部分我就不多说了。之后是

Application.ThreadException  += new  ThreadExceptionEventHandler(ShowErrorBox);

    SharpDevelop为了有效的进行错误报告，因此自己进行了异常的控制。系统出现异常的时候，SharpDevelop会拦截下来弹出它自己的异常提示报告对话框。这个代码就是在这一行实现的。其中 ShowErrorBox 这个方法就在类SharpDevelopMain中，ExceptionBox 定义在/src/Main/StartUp/Dialogs/ExceptionBox.cs中。如果需要进行自己的异常控制，可以学习一下这里的技巧。

2、充满玄机的初始化

string  [] addInDirs  =  ICSharpCode.SharpDevelop.AddInSettingsHandler.GetAddInDirectories(  out  ignoreDefaultPath );
AddInTreeSingleton.SetAddInDirectories(addInDirs, ignoreDefaultPath);

    通过AddInSettingsHandler取得插件的目录，并告知AddInTreeSingleton。AddInSettingsHandler定义在/src/Main/StartUp/Dialogs/AddInTreeSettingsHandler.cs中，它通过读取系统配置（App.config）文件中的AddInDirectory节点的Path属性来确定插件的目录位置，或者你也可以通过自己定义的AddInDirectories节来指定插件目录。如果你没有做这些配置，默认的目录在SharpDevelop运行目录的../Addins目录下。

    通过ServiceManager(服务管理器)加入三个系统默认的服务，消息服务、资源服务、图标服务。这三个服务中，消息服务是显示各种信息提示，另外两个是属于系统的资源，SharpDevelop通过服务来进行统一调用和管理。
ServiceManager.Services.InitializeServicesSubsystem(“/Workspace/Services”);

    初始化其他的服务。SharpDevelop把服务定义在插件树的/Workspace/Services这个路径中，凡是在这个路径下的插件都被认为是服务，因此如果你自己定义了一个服务的话，也需要挂到这个路径下（这里就是系统服务的扩展点了）。

    注意！这一步中，在我们的眼皮子底下悄悄的进行了一个重要的初始化工作。各位看官请看，ServiceManager 定义在/src/Main/Core/Services/ ServiceManager.cs文件中，察看它的InitializeServicesSubsystem方法，我们发现这样一行

AddServices((IService[]) AddInTreeSingleton.AddInTree.GetTreeNode(servicesPath).BuildChildItems(this).ToArray(typeof(IService)));

    在这里，AddInTreeSingleton首次调用了AddInTree（插件树）的实例。按照Singleton模式，只有在首次调用的时候才会初始化实例，这里也是同样如此。整个系统的AddInTree是在这一步中进行了初始化工作，稍候我们将详细介绍AddInTree如何进行初始化工作，先顺便看看服务的初始化。在ServiceManager的InitializeServicesSubsystem方法中，通过AddInTree检索服务插件路径下的所有配置，并通过它来读取、建立具体的对象，然后加入到服务列表中。之后通过一个循环，逐个的调用各个服务的InitializeService方法初始化服务。

    AddInTree的初始化工作容我们稍候再看，先把主体的代码看完。

commands = AddInTreeSingleton.AddInTree.GetTreeNode(“/Workspace/Autostart”).BuildChildItems(null);
for (int i = 0; i < commands.Count - 1; ++i)
{
 ((ICommand)commands[i]).Run();
}

    /Workspace/Autostart是系统自动运行命令的扩展点路径，定义在这个路径下的插件会在系统启动的时候自动运行。在这里，通过插件树初始化建立处于这个路径下的Command（命令），并逐一执行。BuildChildItems方法的功能是建立这个扩展点下的Command列表，我会在介绍AddTree的时候具体说明它的实现。

     主程序代码的最后，初始化完毕、关闭封面窗体，然后执行命令列表中最后一个命令（也就是系统的主界面）。在主界面退出的时候，系统卸载所有的服务。

    在这部分代码中，我们知道了两个系统指定的扩展点路径 /Workspace/Services 和 /Workspace/Autostart ，我们实现服务和指定系统自动运行命令的时候就可以挂到这两个扩展点路径下了。
     托反射的福，ServiceManager.Services可以通过类型（接口）来查找具体的实例，也就是GetServices方法。但是ServiceManager的具体实现我们可以容后再看，这里已经不是最紧要的部分了。
     接下来，我们来看看整个插件系统的核心－AddinTree的代码，看看它是如何通过插件配置进行初始化并建立起整个系统的插件树骨干。

石榴刺猬 2004-10-04 18:55:00

版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。

序

    最近开始学习.Net，遇到了一个比较不错的开源的IDE SharpDevelop。这个开发工具是使用C#开发的，比较吸引我的一点就是它是采用了和Eclipse类似的插件技术来实现整个系统的。而这个插件系统是我最感兴趣的地方，因此开始了一段代码的研究。在本篇之后，我会陆续把我研究的心得写下来。由于是在网吧上网，有诸多不便，因此可能会拖比较长的时间。

一、基本概念

    首先，我们先来对 SharpDevelop 有一个比较感性的认识。你可以从这里下载到它的可执行程序和代码包    http://www.icsharpcode.com/  ，安装的废话就不说了，先运行一下看看。感觉跟VS很像吧？不过目前的版本是1.0.0.1550，还有很多地方需要完善。关于代码和系统结构，SharpDevelop的三个作者写了一本书，各位看官可以参考一下，不过我看过之后还是有很多地方不太理解。

    然后，让我来解释一下什么叫插件以及为什么要使用插件系统。我们以往的系统，开发人员编译发布之后，系统就不允许进行更改和扩充了，如果要进行某个功能的扩充，则必须要修改代码重新编译发布。这就给我们带来了比较大的不方便。解决的方法有很多，例如提供配置等等方法。在解决方案之中，插件是一个比较好的解决方法。大家一定知道PhotoShop、WinAmp吧，他们都有“插件”的概念，允许其他开发人员根据系统预定的接口编写扩展功能（例如PhotoShop中各种各样的滤镜）。所谓的插件就是系统的扩展功能模块，这个模块是以一个独立文件的形式出现的，与系统是相对独立。在系统设计期间并不知道插件的具体功能，仅仅是在系统中为插件留下预定的接口，系统启动的时候根据插件的配置寻找插件，根据预定的接口把插件挂接到系统中。

    这样的方式带来什么样的优点呢？首先是系统的扩展性大大的增强了，如果我们在系统发布后需要对系统进行扩充，不必重新编译，只需要修改插件就可以了。其次有利与团队开发，各个功能模块由于是以插件的形式表现在系统中，系统的每日构造就很简单了，不会因为某个模块的错误而导致整个系统的BUILD失败。失败的仅仅是一个插件而已。

    PhotoShop和Winamp的插件系统是比较简单的，他们首先实现了一个基本的系统，然后在这个系统的基础上挂接其他扩展的功能插件。而SharpDevelop的插件系统更加强大，它的整个系统的基础就仅仅是一个插件管理系统，而你看到的所有的界面、功能统统都是以插件的形式挂入的。在这样的一个插件系统下，我们可以不修改基本系统，仅仅使用插件就构造出各种各样不同的系统。

    现在让我们来看看它的插件系统。进入到SharpDevelop的安装目录中，在Bin目录下的SharpDevelop.exe 和 SharpDevelop.Core.dll是这个系统的基本的插件系统。在Addins目录下有两个后缀是addin的文件，其中一个 SharpDevelopCore.addin 就是它的核心插件的定义（配置）文件，里面定义的各个功能模块存在于Bin/Sharpdevelop.Base.dll 文件中，另外还有很多其他的插件定义在Addins目录下的addin文件中。

    分析SharpDevelop的代码，首先要弄清楚几个基本的概念，这些概念和我以前的预想有一些区别，我深入了代码之后才发现我的困惑所在。

1、AddInTree  插件树
    SharpDevelop 中的插件被组织成一棵插件树结构，树的结构是通过 Extension（扩展点）中定义的Path(路径)来定义的，类似一个文件系统的目录结构。系统中的每一个插件都在配置文件中指定了 Extension，通过Extension中指定的 Path 挂到这棵插件树上。在系统中可以通过 AddTreeSingleton对象来访问各个插件，以实现插件之间的互动。

2、 AddIn 插件
    在 SharpDevelop 的概念中，插件是包含多个功能模块的集合（而不是我过去认为的一个功能模块）。在文件的表现形式上是一个addin配置文件，在系统中对应 AddIn 类。

3、Extension 扩展点
    SharpDevelop中的每一个插件都会被挂到 AddInTree（插件树） 中，而具体挂接到这个插件树的哪个位置，则是由插件的 Extension 对象中的 Path 指定的。在addin 配置文件中，对应于 。例如下面这个功能模块的配置

指定了扩展点路径为 /SharpDevelop/Workbench/Ambiences ，也就是在插件树中的位置。

4、Codon
    这个是一个比较不好理解的东西，在 SharpDevelop 的三个作者写的书的中译版中被翻译为密码子，真是个糟糕的翻译，可以跟Handle(句柄)有一拼了。词典中还有一个翻译叫“基码”，我觉得这个也不算好，不过还稍微有那么一点意思。（这里我原来误写为“代码子”，在评论中有位仁兄说这个翻译不错，现在我觉得也好像确实不错 ^o^）
    根据我对代码的理解，Codon 的功能是描述(包装)一个功能模块（一个功能模块对应一个实现了具体功能的 Command 类）。为了方便访问各个插件中的功能模块， Codon 给各种功能定义了基本的属性，分别是 ID (功能模块的标识)，Name (功能模块的类型。别误会，这个Name 是addin文件定义中Codon的XML结点的名称，ID才是真正的名称)，其中Name可能是Class(类)、MenuItem(菜单项)、Pad(面板)等等。根据具体的功能模块，可以继承Codon定义其他的一些属性，SharpDevelop中就定义了 ClassCodon、MenuItemCodon、PadCodon等等，你可以根据需要自己定义其他类型的Codon。在addin定义文件中，Codon对应于 标签下的内容。例如下面这个定义

<Extension …> 内部定义了一个Codon，<**Class** …>  表示该Codon是一个 Class(类)，接着定义了该Codon的 ID和具体实现该Codon的类名ICSharpCode.SharpDevelop.Services.NetAmbience。运行期间将通过反射来找到对应的类并创建出来，这一点也是我们无法在以前的语言中实现的。

再例如这一个定义

这个扩展点中定义了三个菜单项，以及各个菜单项的名字、标签和实现的类名。这里的Codon就对应于系统中的MenuCodon对象。

5、Command 命令
    正如前文所述，Codon描述了一个功能模块，而每个功能模块都是一个 ICommand 的实现。最基本的 Command 是  AbstractCommand，根据Codon的不同对应了不同的 Command。例如 MenuItemCodon 对应 MenuItemCommand 等等。

6、Service 服务
    插件系统中，有一些功能是整个系统都要使用的，例如文件访问、资源、消息等等。这些功能都作为插件系统的一个基本功能为整个系统提供服务，我们就叫“服务”好了。为了便于访问，这些服务都统一通过 ServiceManager 来管理。其实服务也是一种类型的插件，它们的扩展点路径在目录树中的 /Workspace/Services 中。

    理解了这几个基本的概念之后，就可以看看 SharpDevelop 的代码了。从 src/main/startup.cs 看起吧，之后是addin.cs、addinTree.cs 等等。

   写了两个小时了，休息一下。且听下回分解。

在开发Silverlight程序的时候，经常需要在不同的组件间进行通信。比如点击一个button，可能就需要改变另一个控件的内容。比较直接的办法是使用事件，当然使用MVVM的时候也可以使用command，还可以定义一些全局的变量来保存一些信息等。

Prism提供了几种用于组件间通信的途径，可以使用RegionContext使不同的视图共享数据，也可以借助于容器的力量来使用共享的service来进行通信，或者使用command等。除此之外，Prism还提供了一种基于事件的多播发布/订阅方式的通信机制，使不同的组件之间能够以一种松散耦合的方式来进行通信。这就是本文要介绍的事件聚合(Event Aggregation)。

事件聚合的过程有点像收听广播，首先要有个固定的频率，然后内容就会在这个频率上广播出去，至于有没有人收听，广播电台是不知道的，它只是把内容播送了出去。而其他的人想听广播也不用跑到广播电台，只要知道频率，收听这个频率就可以了。联系广播电台和听众的就是这个频率。

在事件聚合的过程中，事件发布方(publisher)相当于广播电台，事件接收方(Subscriber)相当于听众，而事件自然就相当于频率了。

使用Event Aggregation很简单，只需要知道一个接口和一个类基本上就足够了。接口是IEventAggregator，类是CompositePresentationEvent。

要想发布或订阅事件，自然得先要有事件，所以第一件工作就是要定义事件。Prism提供了一个事件基类CompositePresentationEvent，自定义的事件只需要继承这个类就可以了，泛型代表的是事件发生过程中需要传递的参数类型。如：

1
2
3

public class ReceiveNewEmailEvent : CompositePresentationEvent<MailViewModel>
{
}

上面定义了一个事件，用于在收到新邮件时使用，传递的参数是一个邮件的ViewModel。

使用的时候也很简单，使用IEventAggregator接口中的GetEvent方法来获取事件，然后要么发布出去，要么订阅一下就可以了。

下面是当收到一封新的邮件的时候，发布事件的代码：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

public class EmailReceiver
{
    private IEventAggregator _eventAggregator;
    public EmailReceiver(IEventAggregator eventAggregator)
    {
        _eventAggregator = eventAggregator;
    }
 
    public void ReceiveEmail()
    {
        if (_email != null)
        {   //  当接收到新邮件时，就发布事件，所有订阅了该事件的组件都会接到通知
            _eventAggregator.GetEvent<ReceiveNewEmailEvent>()
                .Publish(_email);
        }
    }
}

可以看到我们直接在构造函数中传递了IEventAggregator类型的参数，如果使用Prism来搭建Silverlight程序的话，那么在默认的Bootstrapper中会在容器中添加IEventAggregator的实例，所以并不需要我们做其它更多的工作。如果对Prism或Bootstrapper不太了解的话，可以参考这两篇文章(Prism简介，Bootstrapper)。

下面是订阅ReceiveNewEmail事件的代码：

1
2
3
4
5
6
7
8
9
10
11
12
13
14

public class MailBox
{
    public MailBox(IEventAggregator eventAggregator)
    {
        eventAggregator.GetEvent<ReceiveNewEmailEvent>()
            .Subscribe(OnReceivedNewEmail);
    }
 
    //  该方法必须为public
    public void OnReceivedNewEmail(MailViewModel mail)
    {
        //  do something
    }
}

这样，发布出去的事件马上就可以被接收到，而且两个组件只是依赖于事件，彼此之间是松散耦合的。

事件可以订阅，也可以退订，甚至可以有选择地接受某些特定的事件。下面以一个模拟的简单的邮箱客户端来演示一下Event Agregation的使用场景。

如图所示,左边是邮件列表，会有一个定时器每隔两秒钟接收到一封邮件，这时邮箱客户端会更新邮件列表，点击左边的列表，会在右边显示邮件的内容。如果点击’将该发信人加入黑名单’，则不会再接受来自该发件人的邮件，如果点击断开连接，则停止接受邮件，再次点击会继续接收邮件。需求大致就是这样了。

首先在启动程序的时候开启一个定时器，每隔两秒钟会接收一封邮件，并发布事件通知有新邮件：

1
2
3
4
5
6
7
8
9
10
11
12
13

public class EmailReceiver
{
    public void Run()
    {
        var timer = new DispatcherTimer();
        timer.Tick += (s, e) => EventAggregatorRepository.EventAggregator
                                    .GetEvent<ReceiveNewEmailEvent>()
                                    .Publish(EmailRepository.GetMail());
        timer.Interval = new TimeSpan(0, 0, 0, 2);
        timer.Start();
    }
 
}

MailList组件会订阅这个事件，并对邮件列表进行更新：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

public partial class MailList : UserControl
{
    private readonly ObservableCollection<MailViewModel> _mails = 
        new ObservableCollection<MailViewModel>();
 
    //  黑名单列表
    private readonly List<string> _refusedSenders = new List<string>();
         
    public MailList()
    {
        InitializeComponent();
 
        MailItems.ItemsSource = _mails;
 
        SubscribeReceiveEmailEvent();
    }
 
    private void SubscribeReceiveEmailEvent()
    {   //  订阅事件的Subscribe方法提供了几个重载方法，除了最简单的直接订阅之外,
        //  还可以指定线程类型(比如如果直接使用System.Threading.Timer的话，
        //  就必须使用ThreadOption.UIThread，否则会报错)，以及是否持有订阅者的引用,
        //  或者指定一个filter来对事件进行过滤
        //  本例中使用的filter是拒绝接受黑名单中包含的发件人发过来的邮件
        EventAggregatorRepository.EventAggregator
            .GetEvent<ReceiveNewEmailEvent>()
            .Subscribe(OnReceiveNewEmail, ThreadOption.UIThread,
            true, (mail) => !_refusedSenders.Contains(mail.From));
    }
 
    public void OnReceiveNewEmail(MailViewModel mail)
    {
        _mails.Insert(0, mail);
    }
}

当点击左边的邮件列表的时候，会在右边的MailContent组件中显示该邮件的信息，这个过程也是通过Event Aggregation来完成的。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

//  NotificationObject是Prism提供的对MVVM的支持的ViewModel的基类
//  可以简化INotifyPropertyChanged接口的实现方式
public class MailViewModel : NotificationObject
{
    public MailViewModel()
    {   //  DelegateCommand也是Prism提供的一种Command类型
        ViewMailCommand = new DelegateCommand(OnViewMail);
    }
         
    public ICommand ViewMailCommand { get; private set; }
 
    public void OnViewMail()
    {
        this.HasRead = true;
        EventAggregatorRepository.EventAggregator
            .GetEvent<ViewEmailEvent>()
            .Publish(this);
    }
}

当点击时，会进入相应的Command逻辑，而MailContent则订阅了ViewEmailEvent，并将传递过来的MailViewModel显示出来：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

public partial class MailContent : UserControl
{
    public MailContent()
    {
        InitializeComponent();
 
        EventAggregatorRepository.EventAggregator
            .GetEvent<ViewEmailEvent>()
            .Subscribe(OnViewEmail);
    }
 
    public void OnViewEmail(MailViewModel mail)
    {
        this.DataContext = mail;
    }
}

当点击将该发信人加入黑名单按钮时,会发布AddRefuseSenderEvent，而接收到这一事件的MailList组件则会更新黑名单，这样filter就会过滤掉黑名单中已经存在的发件人的邮件：

1
2
3
4
5
6
7

public void OnRefusedSendersAdded(string sender)
{
    if (!_refusedSenders.Contains(sender))
    {
        _refusedSenders.Add(sender);
    }
}

如果点击了断开连接或重新连接的话，会发布一个ConnectOrDisconnectMailServerEvent事件。Prism的事件基类并不支持不带参数的事件，也就是说没有办法创建一个不需要传参的事件。所以这里我们使用了object类型作为参数类型，在传递参数的时候直接传了个null过去。

1
2
3

EventAggregatorRepository.EventAggregator
    .GetEvent<ConnectOrDisconnectMailServerEvent>()
    .Publish(null);

而当MailList接收到该事件的时候，首先判断一下是否已经订阅了ReceiveNewEmailEvent事件，如果订阅了就退订，如果没有订阅就重新订阅。这样来达到开启或关闭接收邮件的目的：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54

public partial class MailList : UserControl
{
    private readonly ObservableCollection<MailViewModel> _mails = 
        new ObservableCollection<MailViewModel>();
 
    private readonly List<string> _refusedSenders = new List<string>();
         
    public MailList()
    {
        InitializeComponent();
 
        SubscribeReceiveEmailEvent();
 
        EventAggregatorRepository.EventAggregator
            .GetEvent<ConnectOrDisconnectMailServerEvent>()
            .Subscribe(OnConnectOrDisconnectMailServer);
    }
 
    public void OnConnectOrDisconnectMailServer(object obj)
    {
        //  判断是否已经订阅了该事件
        bool hasSubscribed = EventAggregatorRepository.EventAggregator
            .GetEvent<ReceiveNewEmailEvent>()
            .Contains(OnReceiveNewEmail);
        if (hasSubscribed)
        {
            UnsubscribeReceiveEmailEvent();
        }
        else
        {
            SubscribeReceiveEmailEvent();
        }
    }
 
    private void SubscribeReceiveEmailEvent()
    {
        EventAggregatorRepository.EventAggregator
            .GetEvent<ReceiveNewEmailEvent>()
            .Subscribe(OnReceiveNewEmail, ThreadOption.UIThread,
            true, (mail) => !_refusedSenders.Contains(mail.From));
    }
 
    private void UnsubscribeReceiveEmailEvent()
    {   //  退订事件
        EventAggregatorRepository.EventAggregator
            .GetEvent<ReceiveNewEmailEvent>()
            .Unsubscribe(OnReceiveNewEmail);
    }
 
    public void OnReceiveNewEmail(MailViewModel mail)
    {
        _mails.Insert(0, mail);
    }
}

由于EventAggregation并不需要建立在Prism装配的程序上，为了操作简便，所以并没有使用Prism来管理这个程序，当然也就没有使用容器。所以我用了一个static的全局变量来保存了一个IEventAggregator的实例。

本文为了演示，所以大量地使用了Event Aggregation，希望大家在工作中要仔细斟酌使用，虽然用起来很灵活，但是如果事件太多的话，也会让人有无从下手的感觉，增加维护的难度。

在Prism之Region(1)中，介绍了一些Prism中页面组织以及切换的方式。这一篇将以一个很简单的示例程序来实践一下。

下面是效果图：

先说Log，Prism内置了ILogFacade接口，在Prism提供的QuickStart项目里的Modularity中，有一个CallbackLogger，这里我们直接拿过来使用。然后在PrismRegionShell中放一个TextBox，将log的内容显示在这个TextBox中。值得一提的是，为了让输出新log的直接显示出来，需要将TextBox的滚动条滚动到最下面。这里采用的是如下方法：

1
2
3
4
5
6

public void Log(string message, Category category, Priority priority)
{
    this.LogContainer.Text += string.Format(CultureInfo.CurrentUICulture, "[{0}][{1}] {2}\r\n", category, priority, message);
    //  这段代码的作用是让文本框的滚动条滚动到最底部
    LogContainer.Select(LogContainer.Text.Length, LogContainer.Text.Length);
}

然后说一下左边的导航区。这里放置了一个ItemsControl，并将其设为Region。里面的两个按钮并不是直接写死到xaml里的，而是在两个Module初始化时动态添加进来的。也就是说，这个ItemsControl并不知道自己将要包含哪些项。这里我们使用IRegionManager.RegisterViewWithRegion(RegionNames.NavRegion, typeof(EmptyNavigationItem));这种方式来将视图注册到Region中。这样当该Region显示的时候两个视图才会被初始化。这里需要注意的是，一个Region里需要同时显示多个视图时，视图的顺序问题。比如ItemsControl，哪个先被注册就哪个显示在上面，但是由于Module的加载速度等原因，所以这时两个视图不一定谁在上面。现在我需要指定[导航示例]这个按钮在上，那么Prism为我们提供了ViewSortHintAttribute来解决这个问题。在需要进行排序的视图上添加上相应的attribute就可以了。

1
2
3
4
5

[ViewSortHint("01")]
public partial class NavigationItem : UserControl
 
[ViewSortHint("02")]
public partial class EmptyNavigationItem : UserControl

在初始化导航实例的Module时，将导航示例的视图注册到内容区的Region，这时[上一个]按钮依然处于灰色状态，因为通过RegisterViewWithRegion方法显示的页面是不被记录的。当点击[ViewA][ViewB][ViewC]这三个按钮时，会采用RequestNavigate方法来进行页面的跳转，这时页面跳转的过程会被记录下来，此时就可以通过[上一个]和[下一个]按钮进行页面的前进和后退。

1
2
3
4
5
6
7
8
9
10
11
12

void ToSpecifiedView(string viewName)
{
    UriQuery query = new UriQuery();
    if (viewName == ViewNames.ViewA)
    {
        query.Add("Time", DateTime.Now.ToShortTimeString());
    }
    Uri uri = new Uri(viewName + query.ToString(), UriKind.Relative);
    _regionManager.RequestNavigate(RegionNames.NavDemoShowRegion, uri);
    logger.Log("跳转到视图 [" + viewName + "]", Category.Info, Priority.Low);
    ResetNavigationButtonState();
}

注意这三个视图已经在初始化Module的时候使用IUnityContainer.RegisterType<object, ViewA>(ViewNames.ViewA)方法注册过了。

1
2
3
4
5
6
7
8
9
10
11
12
13

public void Initialize()
{
    logger.Log("初始化Navigation模块", Category.Debug, Priority.Low);
    _regionManager.RegisterViewWithRegion(RegionNames.NavRegion, typeof(NavigationItem));
    _regionManager.RegisterViewWithRegion(RegionNames.MainRegion, 
                                            () => _container.Resolve<NavigationContainer>() );
    _regionManager.RegisterViewWithRegion(RegionNames.NavDemoActionRegion, typeof(ActionController));
 
    //  注意注册的类型的必须是object，因为Prism无法确定视图的类型，所以就用了object
    _container.RegisterType<object, ViewA>(ViewNames.ViewA);
    _container.RegisterType<object, ViewB>(ViewNames.ViewB);
    _container.RegisterType<object, ViewC>(ViewNames.ViewC);
}

ViewA和ViewB都实现了INavigationAware接口，不同之处在于ViewA是在其对应的ViewModel ViewAViewModel类中实现的，而ViewB则直接在Code Behind中实现的。Prism对MVVM提供了良好的支持，因此既可以选择在视图中实现该接口也可以在对应的ViewModel中实现。

1
2
3
4

public bool IsNavigationTarget(NavigationContext navigationContext)
{
    return false;
}

在ViewB中，IsNavigationTarget方法返回了false，而ViewA中则返回了true。可以通过点击三个按钮进行页面跳转，观察log可以发现，ViewA只创建了一次，而ViewB则每次都要重新创建。还有就是在跳转到ViewA的时候传递了参数，可以在OnNavigatedTo方法中取出参数。

1
2
3
4
5
6

public void OnNavigatedTo(NavigationContext navigationContext)
{
    UriQuery query = navigationContext.Parameters;
    string time = query["Time"];
    logger.Log(string.Format("ViewA: 现在时间 {0}", time), Category.Info, Priority.Medium);
}

Prism可以帮助我们开发模块化程序，将程序分割成一个个独立的Module，分别进行开发。然后在程序运行的时候，将各个Module组合到一起，为程序提供各种各样的功能。通常来说，Module是一些视图和功能的集合，那么就需要一种办法来将这些视图以某种形式，在特定的时间展现出来。Prism通过Shell + Region来组织视图的布局，完成视图间的转换等。

如上图所示，Shell相当于ASP.NET中的母版页，它定义了页面的布局、主题等。其中的导航区和内容区是预留出来的需要进行填充内容的部分，也就是Region，起到占位符的作用，程序会在运行时动态地向Region中填充内容。

那么如何将一个区域定义为Region呢？

首先在引入Prism的命名空间

xmlns:prism="http://www.codeplex.com/prism" 如果IDE无法找到这个命名空间的话，需要先注册Prism。

然后在需要定义为Region的控件上加上Attached Property。

<ContentControl prism:RegionManager.RegionName="MainRegion" />

并不是所有的控件都可以作为Region的，需要为需要定义为Region的控件添加RegionAdapter。RegionAdapter的作用是为特定的控件创建相应的Region，并将控件与Region进行绑定，然后为Region添加一些行为。一个RegionAdapter需要实现IRegionAdapter接口，如果你需要自定义一个RegionAdapter，可以通过继承RegionAdapterBase类来省去一些工作。Prism为Silverlight提供了几个RegionAdapter：

• ContentControlRegionAdapter： 创建一个SingleActiveRegion并将其与ContentControl绑定
• ItemsControlRegionAdapter： 创建一个AllActiveRegion并将其与ItemsControl绑定
• SelectorRegionAdapter： 创建一个Region并将其与Selector绑定
• TabControlRegionAdapter： 创建一个Region并将其与TabControl绑定

从图中可以看到，导航区对应的NavigationRegion中四个视图都是亮着的，而内容区对应的ContentRegion中四个视图只有一个是亮着的(橘黄色代表显示在页面中)。ItemsControl本来就是由许多个Item组成的，因此ItemsControlRegionAdapter会创建AllActiveRegion，这种类型的Region中所有Active的视图都会显示在ItemsControl中；而ContentControl只能容纳一个Content，所以ContentControlRegionAdapter创建了一个SingleActiveRegion，其中的视图只有一个是处于Active状态的，会显示在ContentControl中，其它的都是不可见的，需要将它们激活(Active)，才能使其显示。

通常我们并不直接和Region打交道，而是通过RegionManager，它实现了IRegionManager接口。IRegionManager接口包含一个只读属性Regions，是Region的集合，还有一个CreateRegionManager方法。Prism通过RegionManagerExtensions类使用扩展方法为IRegionManager添加了更多的功能。

• AddToRegion： 将一个视图添加到一个Region中。
• RegisterViewWithRegion： 将一个视图和一个Region进行关联。当Region显示的时候，关联的视图才会显示，也就是说，在这个Region显示之前，关联的视图是不会被创建的。
• RequestNavigate： 进行页面切换，将指定的Region中显示的视图切换为指定的视图。

本文开头说过，需要在运行时将分散在各个Module的视图显示在页面特定的位置上。那么首先就需要定义页面显示的地方，即Region。然后就是要定义创建视图的时机和方式。在Prism中有两种方式来定义视图与Region之间的映射关系——View Discovery和View Injection。

View Discovery是以声明式的方式来建立Region和视图之间的关系。如上图中的导航区，需要在导航区显示的时候就将各个导航视图填充到其中。而内容区中也需要一个默认显示的内容视图。因此也可以这样理解View Discovery，就是指定一个Region的默认视图。我们可以使用IRegionManager.RegisterViewWithRegion方法来声明某个Region默认应该显示哪个视图。注意这里是Register，是注册，也就是说不会马上创建该视图。当Region显示在页面中的时候，它会去寻找与自己相关联的视图，并对其进行初始化。

这样做的好处是我们不必关注在什么时候创建视图，一切都会自动完成。缺点就是默认视图是确定的，当需要进行视图转换的时候，这种方式就行不通了。这时候就需要View Injection。

View Injection可以让我们对于Region中显示的视图有更精确的控制。通常可以通过调用IRegionManager.AddToRegion方法或者是IRegionManager.Regions[“RegionName”].Add方法来向一个Region中添加一个视图的实例。对于SingleActiveRegion(ContentControlRegionAdapter会创建这种类型的Region)，可以通过IRegion.Activate方法将一个已经添加到Region中的视图显示出来。当然也可以通过IRegion.Deactivate方法来将视图状态置为非激活或者干脆调用IRegion.Remove方法将视图移除。可以看到，因为要添加的是视图的实例，所以需要仔细地设计在什么时候使用View Injection，以免造成不必要的开销。

在Prism 4.0中新添加了一些导航API，这套API大大地简化了View Injection的流程，它使用URI来进行Region中视图的导航，然后会根据URI来创建视图，并将其添加到Region中，然后激活该视图。导航API的出现不只是为了简化View Injection的过程，它还提供了前进、后退的功能，并且对MVVM模式下的导航有良好的支持，还能够在进行导航的时候传递参数等等。所以推荐的方式是使用新的导航API，也就是使用IRegionManager.RequestNavigate方法。

如果一个页面相对来说不大变化，如导航区，在程序初始化的过程完成后就不会轻易地变动，这时候就较适合于使用RegisterViewWithRegion方法，通常可以在Module的Initialize方法中完成这个过程。

1
2
3
4
5
6
7
8

public void Initialize()
{
    logger.Log("初始化Navigation模块", Category.Debug, Priority.Low);
    _regionManager.RegisterViewWithRegion(RegionNames.NavRegion, typeof(NavigationItem));
    _regionManager.RegisterViewWithRegion(RegionNames.MainRegion, // 两种方式都可以
                                            () => _container.Resolve<NavigationContainer>() );
    _regionManager.RegisterViewWithRegion(RegionNames.NavDemoActionRegion, typeof(ActionController));
}

如果一个区域需要频繁地切换页面的话，如主内容区，可以使用View Injection的方式。

1
2
3
4

IRegionManager regionManager = ...;
IRegion mainRegion = regionManager.Regions["MainRegion"];
InboxView view = this.container.Resolve<InboxView>();
mainRegion.Add(view);

可以看到，这时候已经生成了视图的实例。之前提到过，一个Region可以包含多个视图，这些视图会处于不同的状态，对于ItemsControl类型的Region来说，里面会显示很多个Item，所以添加进去就可以了；但是对于ContentControl这种Region，同一时刻只能显示一个视图，所以在添加进去之后还需要有一个Activate的过程。

使用URI来进行导航只需要提供需要切换的视图的名称就可以，并不需要了解视图的类型，从而达到解耦的目的，并且可以通过URI来进行参数传递。

1
2
3
4
5
6
7
8

public void Initialize()
{  
    //  因为Prism无法确定每个视图都是什么类型，所以就使用了Object，
    //  因此在根据ViewName获取实例时，会使用IServiceLocator.GetInstance<Object>(ViewName)
    _container.RegisterType<object, ViewA>(ViewNames.ViewA);
    _container.RegisterType<object, ViewB>(ViewNames.ViewB);
    _container.RegisterType<object, ViewC>(ViewNames.ViewC);
}

首先注册一下视图的类型，其实就是将视图的名称与视图类型进行一下关联。在导航的时候调用RequestNavigate方法就可以了。

1
2
3
4
5
6

void ToSpecifiedView(string viewName)
{          
    Uri uri = new Uri(viewName, UriKind.Relative);
    _regionManager.RequestNavigate(RegionNames.NavDemoShowRegion, uri);
    logger.Log("跳转到视图 [" + viewName + "]", Category.Info, Priority.Low);
}

Prism提供了UriQuery类来帮助我们在导航的时候传递参数。

1
2
3
4
5
6
7
8
9
10

void ToSpecifiedView(string viewName)
{
    UriQuery query = new UriQuery();
    if (viewName == ViewNames.ViewA)
    {
        query.Add("Time", DateTime.Now.ToShortTimeString());
    }
    Uri uri = new Uri(viewName + query.ToString(), UriKind.Relative);
    _regionManager.RequestNavigate(RegionNames.NavDemoShowRegion, uri, CallbackHandler);   //  回调方法可加可不加
}

上面的代码判断当跳转到ViewA时，传递一个叫做Time的参数。那么怎样在视图中获取传递的参数呢？这里就要提一下INavigationAware接口了。这个接口使视图或者其对应的ViewModel也可以参与到页面导航的过程中来。所以这个接口既可以由视图来实现，也可以由视图的DataContext——通常指的就是ViewModel，来实现。

1
2
3
4
5
6

public interface INavigationAware
{
    bool IsNavigationTarget(NavigationContext navigationContext);
    void OnNavigatedTo(NavigationContext navigationContext);
    void OnNavigatedFrom(NavigationContext navigationContext);
}

当从本页面转到其它页面的时候，会调用OnNavigatedFrom方法，navigationContext会包含目标页面的URI。

当从其它页面导航至本页面的时候，首先会调用IsNavigationTarget，IsNavigationTarget返回一个bool值，简单地说这个方法的作用就是告诉Prism，是重复使用这个视图的实例还是再创建一个。然后调用OnNavigatedTo方法。在导航到本页面的时候，就可以从navigationContext中取出传递过来的参数。

使用导航API的另一个优点就是可以进行页面的前进和后退，一切由Prism完成。这个功能是由IRegionNavigationJournal接口提供的。

1
2
3
4
5
6
7
8
9
10
11

public interface IRegionNavigationJournal
{
    bool CanGoBack { get; }
    bool CanGoForward { get; }
    IRegionNavigationJournalEntry CurrentEntry { get; }
    INavigateAsync NavigationTarget { get; set; }
    void Clear();
    void GoBack();
    void GoForward();
    void RecordNavigation(IRegionNavigationJournalEntry entry);
}

其中CanGoBack和CanGoForward属性表示当前是否可以后退或前进。如果可以的话，可以使用GoBack和GoForward方法进行前进和后退。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37

public class ActionControllerViewModel : NotificationObject
{
    private IRegion _demoShowRegion;
    public bool CanGoBack
    {
        get
        {
            return _demoShowRegion.NavigationService.Journal.CanGoBack;
        }
    }
 
    public bool CanGoForward
    {
        get
        {
            return _demoShowRegion.NavigationService.Journal.CanGoForward;
        }
    }
 
    void ToPrevious()
    {
        _demoShowRegion.NavigationService.Journal.GoBack();
        ResetNavigationButtonState();
    }
 
    void ToNext()
    {
        _demoShowRegion.NavigationService.Journal.GoForward();
        ResetNavigationButtonState();
    }
 
    void ResetNavigationButtonState()
    {
        RaisePropertyChanged(() => this.CanGoBack);
        RaisePropertyChanged(() => this.CanGoForward);
    }
}

导航API还可以控制视图的生命周期，在页面跳转时进行确认拦截(Confirming or Cancelling Navigation)以及其它功能，可以参考 Developer’s Guide to Microsoft Prism。