博客园_Evil 域

LightSwitch 2011 实践之个人汽车仓库 —— 起步

2011-11-23T03:13:00Z

（图片来自Bing图片搜索）

最近，从加拿大辗转来到美国快两个月了，发现没有车的美国生活真是悲惨啊。嗯，是时候下决心买车了。预算有限，打算买辆二手车。于是着手上网查资料。找到了几个比较著名的二手车的论坛，资料虽然不少，但是，数据不集中。总打算着把数据收集下来，形成一个虚拟的、个人的汽车仓库。

本打算用Excel来做，但发现Excel在表现关系的时候有一定的问题，例如，记录Dealer与汽车之间的关系，要么每一个Dealer一个Page，不利于数据搜索；要么就是每一行数据上都放上车行域，冗余数据比较多，而且不利于保持数据的一致性。

于是，萌生了用Visual Studio配合数据库来做一个管理软件的想法。但是，由于业余时间有限，而且这个系统等买完车了以后可能就不再用了，投入产出不成比例。（Access似乎也是一个选择，不过我对Access不是很懂）。

此时正好赶上LightSwitch 2011发布，发现它介乎于Excel和Visual Studio之间，相对于Visual Studio来说，小投入，快速的开发出应用程序，表达关系又比Excel灵活。经过两三天的学习，外加三个小时的实践，初步把Dealer和Car的模块做好了（很多地方有待改进，但已经可以初步使用了。）

运行效果

（点击看大图）

准备工作

准备工作很简单，下载LightSwitch，http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=26830并且安装。

模型设计

（图片来自Bing图片搜索）

这里的模型是指数据模型。在模型设计过程中，要识别出系统中的两个部分，一个是实体，另一个是各个实体之间的关系。

（在话在哪儿听过？大概可能也许或者是关系型数据库设计课程上吧^o^）

简单的说，实体可以看成是生活中具体的事物。例如，我想收集、管理的数据包括Vehicle的和Dealer的两部分，因此，在我的数据模型里，有两个实体：

Vehicle
Dealer

关系无外乎三种：

一对一
一对多
多对多

例如，一个Dealer下面可以有好多部我感兴趣的车，而每一部车物理上只属于一个Dealer，所以它们之间是1对多的关系。

想法确定了以后，就可以动手了。

创建模型

首先，创建一个LightSwitch应用程序。给程序取个又好听又好记的名字或者代号，例如PCI(Personal Car Inventory)。

在程序创建以后，我们可以在主界面上选择Create new table来创建实体。

首先，我们把Table1Item改成Vehicle。并且加一系列的汽车相关的属性。请大家看图。

其中，A处即实体名称。

第一行C处是系统生成的域，其作用是充当数据库中的主键，用于唯一标识一行记录。它是一个自增的整数编号；

VIN是Vehicle的唯一标识编号，就像人的身份证号一样，因此，根据这个号即可确定是哪一辆车，B处，我们把它设置成必须；

（我们可以顺手把它设置成不可重复，方法大家自己猜吧^o^）

其它的属性都是浮云……（根据需要添加、删减）

然后，我们通过界面上的菜单，再添加一个车行的实体。

同样，修改实体名称，添加属性。跟Vehicle一样。唯一有趣的是，大家会发现，这里有两个有趣的数据类型，分别是电话号码和电子邮件格式。（呵呵，LightSwitch想得周到啊，省去了满世界找正则表达式来作验证的功夫了。^o^）

接下来，就可以添加实体间关系了。选中其中任何一个实体，点击设计器上方的Add Relationship按钮。

根据前面的设想，我们选择从Dealer到Vehicle的一对多的关系。

当Dealer下面有车时，我们不允许删除，因此，On Delete行为我们选择Restricted。

如果允许删除有汽车记录的Dealer的记录，那么可以选择Cascade，但要当心，这样子，车行下所有的汽车记录也会被同时删除。

Multiplicity我选择了Zero or one对多，而不是单纯的一对多。这是考虑到在添加Vehicle记录时，我可能还没有Dealer的信息。

这样，我们的数据建模就完成了。如果我们现在F5调试，会看到一个UI的架子，但是，没有任何跟我们的模型有关系的、并且可以操作的内容。因此，我们需要一些UI来提供用户（也就是我自己）操作。

生成界面

（图片来自Bing图片搜索）

生成？没错，生成！一旦数据模型好了以后，我们就可以生成界面了。

在添加关系的按钮的右边，有一个添加Screen的按钮。点击一下，我们看到一个生成UI的向导。

在向导左边，我们可以选择可以生成的窗口的类型。由于我想要一个汽车的列表，并且，这个列表需要带搜索功能。因此，在此，我选择Search Data Screen。并且给窗口取个名字，例如SearchVehicle。Screen Data当然是选择Vehicles啦。

然后我们看到了……一个树状结构-.-||。OK，让我们F5调试，试试看。这次比上次啥都没有看到好，至少，我们看到一个叫Search Vehicle的窗口了。但是，我们似乎还是不能添加汽车记录。因此，我们需要修改界面，增加一个添加记录的按钮。SwitchLight提供了运行时调整界面的功能。点击右上角Design Screen，我们看到了跟设计器类似的一个UI树。它就是我们UI的结构。

展开Data Grid的下面的Command Bar（不是Data Grid Row或者是其它地方的），点击Add，然后选择AddAndEditNew。

AddNew和AddAndEditNew的区别是，AddNew只添加一条空的记录，而AddAndEditNew还会直接打开一个界面让我们给新添加的记录填写内容。

点击Save以后，界面上是不是多了一个绿色加号按钮？这样，我们就可以添加汽车记录了。

用添加AddAndEditNew按钮的方法，添加删、改按钮以后，我们就有了一个可以对汽车记录进行增删改查的系统了。

同样的方法，可以生成一个管理Dealer的界面。

呵呵，这样，一个管理汽车和Dealer的系统便基本成型了。

小结

经过一些努力，我们构建了一个数据模型并且得到了一个很粗糙的系统。对于以数据为中心的程序的开发，LightSwitch是比较高效的。

系统还在继续开发中，LightSwitch还有很多有趣的东西。大家不妨自己下载一个LightSwitch自己试试开发一个自己的系统。

本文链接

让我们更快一点的Visual Studio的技巧们

2011-10-31T23:16:00Z

积跬步以至千里。积小流以成江海。

它们只是不起眼的小技巧。日积月累，它们让我们的工作、学习更有效率，让我们更加专注于逻辑本身，它们是.NET程序员的好朋友，它们是Visual Studio的小技巧……我们，真的认识它们吗？

如果想尽快掌握这些技巧，请打开Visual Studio亲自试一下这些技巧，希望找到你喜欢的技巧的。

(图片来自Bing)

让代码写得再快一些

怎么快速的创建一个类？创建一个应用程序，找个能建类的空地，试试这个：class<Tab><Tab>。

别急，这个技巧还没有完。直接输入想要的类名，然后敲回车。

经常创建属性？试试prop<tab><tab>。

经常写foreach语句？试试foreach<tab><tab>

经常写控制台应用程序？试试cw<tab><tab>

如果有多个高亮区怎么办？用Tab跳转。

怎么找到其它的Code Snippets？试试通过上下文菜单或者快捷键。

让命名空间操作再快一些

经常写文件相关操作但悲剧的发现System.IO不在默认的引用命名空间里面？呵呵，试试这个。直接在方法中输入File+<ESC>+Ctrl+.+<Enter>。

好吧，这个组合看上去有点复杂。让我们来看分解动作，一旦它成为了肌肉记忆，一切都将变得那么自然

首先，File + <ESC>，输入类名File，<ESC>是用于消除Completion List。这时，可以看到File左下角有一个小小的蓝色的小块，这个小块说明已经有Smart Tag可用了；

然后，Ctrl+.用于打开SmartTag，通常，添加using会是第一个选项。

最后，<Enter>应用第一项。

例外：这个技巧不适用于扩展方法。

让命名空间精简而有序

好吧，如果你希望你的类写完以后，让引用的命名数量变得最少并且按字母排序，你可以用下面这个组合：<Application>+<o>+<a>。

不知道<Application>键是哪一个键？我也不知道，从这里借个名称。其实就是右Ctrl键左边的那一个，用来调出上下文菜单的键。

让继承抽象类和实现接口再快一些

当手上有一个抽象类，有N个抽象方法，当抽象类被继承时，重写这些方法名称费时费力又无聊——像是在抄写方法名。为什么不让Visual Studio来做呢？

为了方便大家动手，请把下面的代码复制、粘贴到Visual Studio中：

public abstract class Person

public abstract void Walk();

public abstract void Eat();

class Baby : Person

然后把光标放到Baby后面的Person上，看到Smarttag了？那就Ctrl+.+<Enter>吧。

此方法同样适用于接口。

让重命名再快一些

经常为了偷懒取个比较短的变量名？有的team会不允许使用缩写作为变量名，而全称又太长，这时，可以先写短名，然后直接改名。例如，有些团队不允许单字母的变量，像这里的i：

for (int i = 0; i < 100; i++)

System.Console.WriteLine(i + 1);

首先，请通过for<tab><tab>生成for语句，然后使用cw<tab><tab>来生成WriteLine语句。

然后，把光标定位在第一个i的后面，输入ndex。

看到SmartTag的提示小块了？Ctrl+.+<Enter>

写在最后

除了给引用命名空间引用排序外，其实，我们只接触到了两个快捷键：

<tab><tab>

Ctrl+.

前者主要用于插入code snippets，后者则用于调用SmartTag。

这些不是什么高深的技术，但却是写代码时天天要用到的技巧。有这些小技巧的日积月累，相信会水滴石穿。

这些技巧不能帮助你写出更出色的代码来，但是，习惯以后，它可以提升我们写代码的速度，进而让我们有更多的时间花在提高代码质量上。

本文链接

实战 WPF Jump List 编程

2011-09-21T22:45:00Z

（图片来自Bing搜索）

Windows 7提供了JumpList，可以通过右击任务栏上的图标，跳出快捷菜单，为用户操作应用程序提供一个捷径。例如，Live Messenger为我们提供了注销和退出的功能：

WPF为Jump List提供了支持。

我们来实现如下一个Jump List：

这个JumpList有三个分组，分别是：Function，3rd Party Applications和Window Control。
Function里提供一个Hello的项，弹出一个Hello JumpList对话框；
3rd Party Appliation里，我们可以直接调用计算器；
Window Control里提供两个功能，另外是最大化和最小化窗口。

如果没有接触过Jump List的编程，现在，请花2分钟时间大概构想一下实现方法吧……（2分钟过去了）

来看看结果是不是跟你想像的一样。

基础

明白JumpList的结构

这个不多说，请大家看图：

我们将结合WPF来看看JumpTask的开发。

JumpList的XAML支持

WPF提供了叫JumpList的Attach属性来支持JumpList。大概的样子如下：

<Application …
    <JumpList.JumpList>
        <JumpList>
            <JumpTask Title="Say Hello" Arguments="hello" />
        </JumpList>
    </JumpList.JumpList>
</Application>

仔细观察高亮的代码行，它有一个Title属性，大家一定都知道它是干什么的了。Arguments属性也可以理解，传入参数。

读到这里是不是有一个疑问：为什么没有类名或者函数名称之类的？这个JumpTask将由谁哪个函数来执行呢？

JumpTask执行逻辑

卖个关子，先。请大家新建一个WPF应用程序：

打开App.XAML，复制、粘贴从以上代码
在项目属性中去掉Enable the Visual Studio hosting process的对勾

F5调试
右击应用任务栏上的图标，是不是已经看到对应的JumpList项了？

点击调用Say Hello。

看到了什么？没错，一个新的应用程序实例被打开了。因此，Arguments的调用者，就是应用程序本身，再精确点说，是Main函数。

如果应用程序名叫JumpList.exe，那么当用户点击Say Hello时，相当于调用了JumpList.exe hello。

既然每次点击JumpList上的项都会产生一个新的应用程序实例，那么如何实现让它弹出Hello JumpList的对话框？

这里提供一种简单实现：

我们重写App类的OnStartup方法，利用Environment.GetCommandLineArgs()方法来获取参数，如果参数为hello，那么显示对话框，然后马上结束当前实例。

为了减小干扰，这里用了硬编码来读取第一个参数。实际项目慎用。

   1:          protected override void OnStartup(StartupEventArgs e)

   2:          {

   3:              base.OnStartup(e);

   4:              // Get all command arguments

   5:              var arguments = Environment.GetCommandLineArgs();

   6:              // Execute when there are arguments other than the application itself.

   7:              if (arguments.Length > 1)

   8:              {

   9:                  // Lower the character.

  10:                  var argument = arguments[1];

  11:                  if (argument.Equals("hello", StringComparison.InvariantCultureIgnoreCase))

  12:                  {

  13:                      // Execute when the parameter equals hello.

  14:                      MessageBox.Show("Hello JumpList");

  15:                      // Shutdown the new instance.

  16:                      App.Current.Shutdown();

  17:                  }

  18:              }

  19:          }

请大家按照这个思路编写代码，看看执行效果：

JumpTask调用第三方应用

根据我们对JumpList的理解，不难推测，JumpTask调用第三方应用将异常的简单，例如，我们可以通过以下代码调用计算器（calc.exe）：

<JumpTask Title="Calculator" ApplicationPath="calc" />

利用ApplicationPath属性来指定要执行的应用程序名称。

Arguments属性仍然有效。这也就是说，如果我们把ApplicationPath指向自己，并且传入对应的参数，即可达到前一个例子的效果。

为JumpTask项目分组

对JumpTask的分组也相当简单，只要设置JumpTask项的CustomCategory属性即可。例如：

<JumpList.JumpList>
        <JumpList>
            <JumpTask Title="Calculator" ApplicationPath="calc"  CustomCategory="3rd Party Applications" />
            <JumpTask Title="Say Hello" Arguments="hello" CustomCategory="Function" />
        </JumpList>
    </JumpList.JumpList>

需要注意的是，分组出现的顺序是从后向前的。例如，上面的JumpList中，最后定义的分组是Function，那么，在JumpList中，最先出现的分组就是Function。

JumpTask项的图标设置

JumpTask有两个属性用以控制图标：

IconResourcePath指向图标所在的位置
IconResourceIndex设置图标的序号（0为起始序号）

例如：

<JumpTask Title="Calculator" ApplicationPath="calc"  CustomCategory="3rd Party Applications" IconResourcePath="%windir%\system32\calc.exe" />
            <JumpTask Title="Say Hello" Arguments="hello" CustomCategory="Function" IconResourcePath="%windir%\System32\imageres.dll" IconResourceIndex="18" />

分别取到了计算器本身的第0个图标和imageres.dll的第18个图标。

如果不想有图标，那就把IconResourceIndex设置成-1。

至此，我们了解了WPF中JumpTask编程的基本内容，包括JumpList的结构，调用逻辑等。

但是，从用户的角度出发，JumpList往往应该是针对当前应用实例的。例如，我们列出的目标JumpList中，包括了最大化、最小化。当用户点击它们的时候，肯定不会期望应用程序新建一个实例，并且最大化、最小化新实例。

要实现这样的功能，需要涉及到两个常用的WPF编程技巧，分别是：

单一应用程序实例
进程间交互

提高

（图片来自Bing搜索）

实现思路：

首先，当用户点击JumpTask项时，如果已经有进程实例存在，那么，新实例将终止自己——即实现单一应用程序实例；

其次，新实例终止自己前，需要告诉原有实例，用户调用了什么操作——新老进程间交互；

我们将问题分解，分两部分实现：

单一应用程序实例的实现

参考：Single Instance WPF Application in .NET 3.x介绍了两种实现方法：

检查进程名——有的项目通过此方法检查安装程序，结果导致与系统进程名冲突，不推荐使用。
使用WindowsFormsApplicationBase——文章里有源代码，大家可以试试。

这里另外介绍使用信号量（Mutex）的方法，来实现WPF应用程序单一实例。

.NET提供了Mutex类（System.Threading.Mutex），它的构造方法中有一个重载，接受一个名称，并且输出是否新建了信号量。我们可以利用这个重载，为应用程序找一个唯一的标识。

最容易想到的方法就是生成一个GUID。

Visual Studio自带了一个GUID在的生成器，可以通过Tools | Create GUID打开，把对应的GUID复制出来即可。

接下来，我们在OnStartup中，创建信号量，并且在OnExit中，销毁它。

主要代码如下：

   1:  using System;

   2:  using System.Threading;

   3:  using System.Windows;

4:

   5:  namespace WpfApplication20

   6:  {

   7:      public partial class App : Application

   8:      {

   9:          Mutex _singleInstanceMutex;

  10:          private const string _applicationGUID = "38038762-99E1-4F8A-A937-1AE8A3308298";

11:

  12:          protected override void OnStartup(StartupEventArgs e)

  13:          {

  14:              base.OnStartup(e);

  15:              bool isNewMutex;

  16:              _singleInstanceMutex = new Mutex(false, _applicationGUID, out isNewMutex);

  17:              if (isNewMutex)

  18:              {

  19:                  //1st instance of current application

  20:              }

  21:              else

  22:              {

  23:                  // Not the 1st instance

  24:                  var arguments = Environment.GetCommandLineArgs();

  25:                  // Execute when there are arguments other than the application itself.

  26:                  if (arguments.Length > 1)

  27:                  {

  28:                      // Deal with the command argumens.

  29:                      // ...

  30:                  }

  31:                  else

  32:                  {

  33:                      MessageBox.Show("Sorry, only one instance of the applciation is allowed!", "Multiple Instances", MessageBoxButton.OK, MessageBoxImage.Error);

  34:                  }

  35:                  // Shutdown the new instance.

  36:                  App.Current.Shutdown();

  37:              }

  38:          }

  39:      }

  40:  }

用WCF实现进程间交互

要实现通过JumpTask来最大化、最小化，除了不让一个以上的应用程序实例出现以外，我们还需要在新进程被Shutdown之前，告诉第一个实例的进程，进行最大化或者最小化操作。这就涉及到进程间交互。

我们知道，在OS中，进程之间的资源是相互独立的。要让进程之间进行通讯，必须付出努力。

以前，在.NET中，我们通过Remoting来进行进程间交互。（我们可以通过维基百科来查查Remoting的底细。）

现在Remoting已被WCF代替。我们下面就来看如何用WCF，实现最大化、最小化窗口的方法。

你不需要太多的关于WCF的知识。如果你没有接触过WCF，那么，记住下面两件事情和一些基本概念就可以了：

逻辑上，WCF分客户端和服务端；
客户端和服务端通过端点（EndPoint）进行通讯。ABC进行通讯。什么是ABC呢？ABC就是Address，Binding和Contract。

这里有一些基本概念，大家留一个印象（描述并不一定很精确，大家参考MSDN啊）：

Address：一个Uri，用于表达服务所在位置；
Binding：定义通讯的方法，其实就是在服务端与客户端约定好，怎么通讯，是http呢还是namedpipe呢还是TCP……不明白细节没有关系，只要在服务器与客户端使用一致的Binding类型即可。
Contract：定义服务提供的具体的方法及参数——我们往往使用.NET接口作为协议。

有了这些基本概念以后，我们就可以着手实现功能了。

首先，我们要想清楚，在我们的例子中，谁是客户端，谁是服务端？

……（想ing…）

由于是第二个应用程序实例要调用第一个应用程序实例功能（最大化、最小化），因此，第一个应用程序实例需要提供服务；而第二个应用程序实例作为客户端来调用服务。
第一个应用程序的实例的代码和第二个应用程序的实例的代码……是同一份，因此，无论是服务还是客户端代码，都应该在同一个项目中。
通过前面对单一应用程序实例的实践，我们有办法判断代码是第一个实例还是后来的实例了，因此，我们可以在第一个实例的时候作为服务端创建服务；以后每次调用服务，并结束进程。

这样，终于可以动手了，先写服务端代码：

第一步：添加引用：System.ServiceModel和System.Runtime.Serialization。

第二步：实现服务——编写实现最大化和最小化的类：

   1:      public class MMService

   2:      {

   3:          public void Max()

   4:          {

   5:              App.Current.MainWindow.WindowState = System.Windows.WindowState.Maximized;

   6:          }

7:

   8:          public void Min()

   9:          {

  10:              App.Current.MainWindow.WindowState = System.Windows.WindowState.Minimized;

  11:          }

  12:      }

第三步，抽象出服务接口，作为服务协议（ABC中的C）：

我们可以通过Visual Studio提供的重构功能，自动抽象出接口代码，然后，为接口添加协议所需要的属性：ServiceContract和OperationContract。

   1:  using System;

   2:  using System.ServiceModel;

   3:  namespace WpfApplication20

   4:  {

   5:      [ServiceContract]

   6:      public interface IMMService

   7:      {

   8:          [OperationContract]

   9:          void Max();

10:

  11:          [OperationContract]

  12:          void Min();

  13:      }

  14:  }

第四步，为服务添加一个Host，并且在实用实例启动时，把服务打开。

   1:          private ServiceHost _serviceHost;

   2:          protected override void OnStartup(StartupEventArgs e)

   3:          {

   4:              base.OnStartup(e);

   5:              // ...

   6:              if (isNewMutex)

   7:              {

   8:                  //1st instance of current application

   9:                  _serviceHost = new ServiceHost(typeof(MMService), new Uri("net.pipe://localhost"));

  10:                  _serviceHost.AddServiceEndpoint(typeof(IMMService), new NetNamedPipeBinding(), "MMService");

  11:                  _serviceHost.Open();

  12:              }

  13:              else

  14:              {

  15:                  // Not the 1st instance

  16:                  // ...

  17:              }

  18:          }

关注一下第10行，其实就是定义了：C – IMMService, B – NetNamePipeBinding 和 A – net.pipe://localhost/MMService

地址其实是分成两部分定义的，一部分是baseAddress，是host的地址；另一部分是服务地址：MMService。

这样，服务器端就暴露了一个叫MMService的EndPoint。

客户端代码写在不是第一个实例中：

第一步：根据ABC，创建一个ChannelFactory对象：

ChannelFactory<IMMService> channelFactory = new ChannelFactory<IMMService>(new NetNamedPipeBinding(), "net.pipe://localhost/MMService");

这行代码中，Binding和Address显而易见了，Contract在哪儿？

第二步：通过CreateChannel方法，创建一个在客户端的代理类，并且调用Max/Min的方法：

   1:                  var proxy = channelFactory.CreateChannel();

   2:                  proxy.Max();

这样，我们就可以F5来调试当前的应用程序了。大家会发现，如果保持现在的代码，第二次调用当前应用程序实例时，第一个实例会被最大化。

这跟我们预想的效果还有一点点的差距……但不难解决，限于篇幅，就不再赘述了。

资源：

残缺版源代码（无论点击最大化还是最小化，窗口都最大化）：

改进版二进制文件：

（改进版中仍然有一个明显的bug哦）

本文链接

实战Bing MAP REST服务的封装、调用

2011-08-29T21:58:00Z

什么是REST服务？

如果您不知道答案，那么，请您花5分钟时间来浏览一下这个教程：

Learn REST: A Tutorial

(就5分钟，您就读一下吧。)

(图片来自Bing搜索)

您已经知道了，由于REST是基于HTTP协议的服务，它有以下优点：

平台无关——例如用Unix架的服务器提供的服务，可以在PC、MAC等其它终端，甚至手机上调用；
语言无关——C#架的服务，可以被Java甚至JavaScript调用；
便于跨防火墙存取数据；

接下来，用一个例子，来说明怎么设计一组类（三个），用来封装并调用REST服务。

（如果你想知道用.NET怎么创建REST服务？请花30分钟左右看看：An Introduction To RESTful Services With WCF）

任务：封装Bing地图的REST服务，来计算一个两地的驾驶距离。（你知道从徐家汇开车到人民广场要多少路吗？ ）

要调用一个REST服务，要知道两个要素：

URL模板——发送请求的字符串的格式；
XML响应——用XML表达的返回的结果；

Bing Map的URL模板如下(来源于MSDN)：

http://dev.virtualearth.net/REST/v1/Routes/travelMode?wayPoint.1=wayPoint1&heading=heading&waypoint.2=wayPoint2&wayPoint.n=wayPointn

&optimize=optimize&avoid=avoidOptions&distanceBeforeFirstTurn=distanceBeforeFirstTurn&timeType=timeType&dateTime=dateTime&maxSolutions=maxSolutions

&routePathOutput=routePathOutput&tolerances=tolerance1,tolerance2,tolerancen&distanceUnit=distanceUnit&key=BingMapsKey

-.-||好长的字符串啊。

对应的XML响应就不“如下”了，大家根据需要看MSDN吧。为了便于直观理解，MSDN同时提供了一些例子。

另外，对于Bing地图的开发，还需要有一个对应的应用程序Key，这个Key用于识别调用Bing地图服务的应用程序。大家可以在这儿免费申请和查看开发者KEY。

我的Key是：我不告诉你。您就自己申请一个吧。

这样，准备就做得差不多了。

既然是实战，达成目标优先，因此，设计一个类来达成目标。

这个类得有一个方法可以计算距离：

它的返回值是一个double类型；
它需要根据参数来计算距离，最直观的参数就是URL；
我们可以用WebClient来触发一个进行一个Http请求；
返回的结果是HTML，因此，我们LinqToXml来进行处理；

所以，就有了如下的代码：

   1:  using System;

   2:  using System.Linq;

   3:  using System.Net;

   4:  using System.Xml.Linq;

5:

   6:  namespace BingMapRouteDistanceDemo

   7:  {

   8:      public class RouteDistanceCalculator

   9:      {

  10:          public double GetDistance(string requestUrl)

  11:          {

  12:              WebClient client = new WebClient();

  13:              string resultXML = client.DownloadString(requestUrl);

  14:              XElement xml = XElement.Parse(resultXML);

  15:              string resultString = xml.Descendants("TravelDistance").First().Value;

  16:              return Convert.ToDouble(resultString);

  17:          }

  18:      }

  19:  }

嗯，您是不是已经准备拍砖了？ （千万冷静，除非您正想换显示器愁没借口……）

至少，这个类基本上能够正常用（其实是用不起来的）。如果把这样一个类应用到项目中，会有哪些问题？

您一定已经看出来了，至少有两个明显的问题（欢迎补充）：

输入参数是一个字符串——而且是一个长长的字符串
- 构建这个字符串的任务交给用户，效率低，函数难用且极易出错；
- 这么一串长长的字符串中出了错，你也不知道到底哪儿错了，得一个一个排查。

让我们看看，如果要调用这个类，大概的代码是什么样子的：

   1:              RouteDistanceCalculator route = new RouteDistanceCalculator();

   2:              Console.WriteLine(

   3:                  route.GetDistance(

   4:                  @"http://dev.virtualearth.net/REST/V1/Routes?wp.0=37.779160067439079,-122.42004945874214&wp.1=32.715685218572617,-117.16172486543655&key=BingMapsKey")

   5:                  );

如果您熟悉数据库编程，想想手动编写数据库连接字符串的感觉就有体会了。

当前类既处理输入（URL），还处理输出（XML），不符合单一责任原则——不解释；

在封装REST服务时，这两个问题也较普遍。我们分别来解决它们。

(图片来自Bing搜索)

首先，我们可以构建一个专门用于创建URL请求的类，这个类有以下特征：

把提供给用户输入的每一个参数对应于一个属性；参数的值对应于属性的值；
暴露一个方法，用于返回最终的URL；

示意代码如下，文后附完整项目。

   1:      public class RouteDistanceCalculator

   2:      {

   3:          // Pay attention to change of the parameter type.

   4:          public double GetDistance(RouteRequestBuilder requestBuilder)

   5:          {

   6:              WebClient client = new WebClient();

   7:              // Builder have the responsibility of forming query string.

   8:              string resultXML = client.DownloadString(requestBuilder.GetQueryString());

   9:  ...

  10:          }

  11:      }

12:

  13:      public class RouteRequestBuilder

  14:      {

  15:          #region Public Method

  16:          /// <summary>

  17:          /// Go over properties one by another to construct the query uri.

  18:          /// </summary>

  19:          public virtual string GetQueryString()

  20:          {

  21:              StringBuilder resultBuilder = new StringBuilder();

  22:              resultBuilder.Append(BasicQueryUri);

  23:              // Construct for travel mode

  24:              resultBuilder.AppendFormat("{0}?", TravelMode.ToString());

  25:              // ...

  26:              return resultBuilder.ToString();

  27:          }

  28:          #endregion

29:

  30:          #region Query conditions

  31:          public IList<Location> WayPoints { get; set; }

  32:          public TravelMode TravelMode { get; set; }

  33:          public TransitTimeType TravelTimeType { get; set; }

  34:          public DateTime TravelDateTime { get; set; }

  35:          #endregion

  36:      }

RouteRequestBuilder就是这么一个前文描述的类。其分为两大部分，15到28行Public Method暴露了一返回URL的方法GetQueryString；而30到35行的Query Conditions把需要用户输入的查询条件做成的属性。

这样，用户就只要创建对象并给它的属性赋值，再不用担心构建字符串的问题了。

接下来，看输出结果。XML是REST服务输出的普遍形式。如果像文中一样，直接处理XML，一旦返回的XML格式调整或者扩展，我们需要一个方法一个方法的修改。

假如我们要多个结果，并且结果还被多处调用，那么，对于项目来说，结果是灾难性的。

所以，您已经想到了，可以把处理结果的逻辑封装起来形成一个类，这个类有如下特征：

有一个方法或者属性，可以获取到原始的结果——例子中webClient返回的XML；
把用户关心的内容，以属性的形式暴露出来；
用户无须知道XML与属性值的对应关系；

由于用户不需要知道XML的细节，因此，对于这个类来说，如果把结果保存到ResultString属性中，我们不需要暴露它的读方法，意味着这是一个“只写”属性，那么，我们就可以把它做成一个方法。

在这里，我们只关心行驶距离，因此，它应该有一个叫Distance的属性，返回一个double类型的值。

形成的类主要代码如下：

   1:      public class RouteResponseResolver

   2:      {

   3:          #region Properties

   4:          /// <summary>

   5:          /// Get distance of the route.

   6:          /// </summary>

   7:          public double Distance

   8:          {

   9:              get

  10:              {

  11:                  return GetDistance();

  12:              }

  13:          }

  14:          #endregion

15:

  16:          #region Private Methods

  17:          private double GetDistance()

  18:          {

  19:              // Covert xml into property

  20:          }

  21:          #endregion

22:

  23:          #region Public Methods

  24:          /// <summary>

  25:          /// Update the result string to resolve with

  26:          /// </summary>

  27:          /// <param name="resultString"></param>

  28:          public void UpdateResultString(string resultString)

  29:          {

  30:              // Update result string

  31:          }

  32:          #endregion

  33:      }

对应的，我们就需要修改一下RouteDistanceCalculator类，把RouteResponseResolver也作为一个参数传入：

   1:      public class RouteDistanceCalculator

   2:      {

   3:          public double GetDistance(RouteRequestBuilder requestBuilder, RouteResponseResolver resultResolver)

   4:          {

   5:              WebClient client = new WebClient();

   6:              string resultXML = client.DownloadString(requestBuilder.GetQueryString());

   7:              resultResolver.UpdateResultString(resultXML);

   8:              return resultResolver.Distance;

   9:          }

  10:      }

费了这么多神，我们得到了什么？让我们再来看一下，现在的用户如何来调用RouteDistanceCalculator.

   1:          static void Main(string[] args)

   2:          {

   3:              RouteDistanceCalculator route = new RouteDistanceCalculator();

   4:              RouteRequestBuilder requestBuilder = new RouteRequestBuilder()

   5:              {

   6:                  TravelMode = TravelMode.Driving,

   7:                  WayPoints = new List<Location>()

   8:                  {

   9:                      // Location for Xujiahui, Shanghai

  10:                      new Location(){ Latitude=31.1970231682062, Longitude=121.441092118621},

  11:                      // Location for people's square

  12:                      new Location(){ Latitude=31.233944, Longitude=121.467813}

  13:                  }

  14:              };

  15:              RouteResponseResolver responseResolver = new RouteResponseResolver();

  16:              var distance = route.GetDistance(requestBuilder, responseResolver);

  17:              Console.WriteLine("Drive distance between Xujiahui & People's square are: {0} km.", distance);

  18:          }

可以看到，通过RouteRequestBuilder类，我们指定了路径类型为驾程，一共涉及到两个点，分别是徐家汇和人民广场；我们用responseResolver来解析查询到的结果……

由于请求不再要求用户输入字符串，出错机率减小，即使出错，调试也相对容易许多；
对于RouteDistanceCalculator来说，请求和响应解析的类是可以被替换的；

最后，揭晓徐家汇到人民广场的车程：

(图片来自Bing搜索)

最后的后面：

下一步……在这里的请求生成和响应解析类都是具体类，如果把它们抽象成接口，会进一步降低它们之间的耦合性。

小结一下：

一个REST服务总可以封装成三个类：

调用类——调用以下两个类；
请求生成类——以属性形式接受查询条件的输入，提供生成请求URL的方法；
响应解析类——用于解析返回的结果，以属性返回用户感兴趣的数据；

如果将后两个类抽象成对应接口，即可实现请求、响应与调用类之间的解耦合。

资源：

Learn REST: A Tutorial

An Introduction To RESTful Services With WCF

Bing Map开发中心

Bing Map SDK

示例代码：为了方便大家看上下类的关系，我把所有的类全放在一个文件里了，一般不推荐这样做；

另外，使用示例前，请把文件底部的BingMapKey换成您自己的Key。

本文链接

选好 Async 函数的返回类型

2011-08-15T02:13:00Z

在C# 5.0功能之Async一瞥中，简单的介绍了Async CTP的使用，我们一起领略了下一版本的C#可能给我们带来的强大而简单的编写异步执行的代码的方法。

文中提到一个异步方法的返回值有三个选项：

void
Task
Task<T>

什么时候使用哪一种返回类型，是有讲究的。一不小心使用不当，会让代码产生意想不到的结果。为了避免在将同步代码改成异步代码时出现返回类型选择不恰当的情况，给大家介绍ASync选择返回类型的三法则。

（图片来自Bing搜索）

（还是申明一下：本文的例子基于Async CTP SP1 Refresh完成。由于 Async还处于CTP阶段，很多东西还在讨论，因此，也许到正式发布的时候，细节还会变动。）

假设有一个学生类，包括学号ID和姓名Name属性：

   1:      public class Student

   2:      {

   3:          public int ID { get; set; }

   4:          public string Name { get; set; }

5:

   6:          public override string ToString()

   7:          {

   8:              return string.Format("ID: {0}, Name: {1}.", ID, Name);

   9:          }

  10:      }

然后，有一组学生记录的StudentRepository：

   1:      public class StudentRepository

   2:      {

   3:          ICollection<Student> storage;

4:

   5:          public ICollection<Student> GetStudents()

   6:          {

   7:              var studentCollection = CreateStudents();

   8:              UpdateNameUnknownStudent(studentCollection);

   9:              return studentCollection;

  10:          }

11:

  12:          private ICollection<Student> CreateStudents()

  13:          {

  14:              Thread.Sleep(2000);

  15:              storage = new Collection<Student>()

  16:              {

  17:                  new Student(){ ID=1 },

  18:                  new Student(){ ID=2 }

  19:              };

  20:              return storage;

  21:          }

22:

  23:          private void UpdateNameUnknownStudent(ICollection<Student> studentCollection)

  24:          {

  25:              foreach (var student in studentCollection)

  26:              {

  27:                  Thread.Sleep(1000); // Someoperation time like db access or so.

  28:                  student.Name = student.Name ?? "Unknown";

  29:              }

  30:          }

  31:      }

其中，12行的CreateStudents方法模拟了学生对象的创建，它返回一个学生集合；

第23行UpdateNameUnkownStudent方法遍历学生集合，并且，如果学生的姓名为空，将学生姓名设置成“Unknown”。

第5行GetStudents()作为公开的接口，先后调用CreateStudnets和UpdateNameUnknownStudent方法，并将结果返回。

为了模拟现实代码中例如数据库等操作的处理时间，在第14行和第27行分别加了延时。

然后，创建一个WPF UI，调用上面的StudentRepository类，把结果存放到一个Label中。

界面如下：

Demo按钮的事件处理代码如下：

   1:          private void btnDemo_Click(object sender, RoutedEventArgs e)

   2:          {

   3:              StudentRepository repository = new StudentRepository();

   4:              var studentCollection = repository.GetStudents();

   5:              StringBuilder builder = new StringBuilder(studentCollection.Count);

   6:              foreach (var student in studentCollection)

   7:              {

   8:                  builder.AppendLine(student.ToString());

   9:              }

  10:              lblResult.Content = builder.ToString();

  11:          }

执行代码，虽然代码能够得到正确结果，但是，在点击Demo按钮后，界面出现了几秒钟的死锁。为了提供更好的用户体验，我们决定把学生创建和为空名学生记录添加Unknown的方法改写成异步方法。

（图片来自Bing搜索）

首先看CreateStudents方法，它返回一个ICollection<Student>的集合。

法则一：对于需要返回对象的方法，我们添加async关键字后，改为返回Task<T>，也即，改为：

   1:          private async Task<ICollection<Student>> CreateStudentsAsync()

   2:          {

   3:              await TaskEx.Delay(2000);

   4:              storage = new Collection<Student>()

   5:              {

   6:                  new Student(){ ID=1 },

   7:                  new Student(){ ID=2 }

   8:              };

   9:              return storage;

  10:          }

接下来，我们看UpdateNameUnknownStudent方法，由于它不返回结果，我们直接加上async：

   1:          private async void UpdateNameUnknownStudentAsync(ICollection<Student> studentCollection)

   2:          {

   3:              foreach (var student in studentCollection)

   4:              {

   5:                  await TaskEx.Delay(1000); // Someoperation time like db access or so.

   6:                  student.Name = student.Name ?? "Unknown";

   7:              }

   8:          }

相应的GetStudent方法和Demo按钮也加上async关键字和await等待结果后，重新编译运行。点击Demo按钮。我们发现，界面是不死锁了，但是结果出错了（就说会产生意想不到的结果吧）：

ID: 1, Name: .
ID: 2, Name: .

显然，UpdateNameUnknownStudentAsync没有运行。让我们来仔细的看一下执行流。

首先，Demo按钮Click事件调用者调用GetStudentAsync，为理清调用层次，我们记btnDemo_Click方法为L1方法：

   1:          private async void btnDemo_Click(object sender, RoutedEventArgs e)

   2:          {

   3:              StudentRepository repository = new StudentRepository();

   4:              var studentCollection = await repository.GetStudentsAsync();

   5:              StringBuilder builder = new StringBuilder(studentCollection.Count);

   6:              foreach (var student in studentCollection)

   7:              {

   8:                  builder.AppendLine(student.ToString());

   9:              }

  10:              lblResult.Content = builder.ToString();

  11:          }

当执行到第4行时，遇到await关键字，调用GetStudentsAsync方法（记为L2方法），并且进入等待状态，等待L2结果。

GetStudentAsync(L2)此时代码如下：

   1:          public async Task<ICollection<Student>> GetStudentsAsync()

   2:          {

   3:              var studentCollection = await CreateStudentsAsync();

   4:              UpdateNameUnknownStudentAsync(studentCollection); // We have a problem here …

   5:              return studentCollection;

   6:          }

当它执行第3行代码，调用CreateStudnetsAsync以后，遇到await关键字，等待CreateStudentAsync的完成。

CretaeStudent方法完成后，L2方法继续执行到调用UpdateNameUnknownStudentAsync方法（记为L3方法）：

   1:          private async void UpdateNameUnknownStudentAsync(ICollection<Student> studentCollection)

   2:          {

   3:              foreach (var student in studentCollection)

   4:              {

   5:                  await TaskEx.Delay(1000); // Someoperation time like db access or so.

   6:                  student.Name = student.Name ?? "Unknown";

   7:              }

   8:          }

L3执行到第5行时，遇到了await，当前线程开始等待TaskEx.Delay完成；同时，它会检查它的调用者（L2）是否有代码可以在当前线程上执行。由于在L2中，并没有await L3方法，因此，当L3中await一个结果时，L2所在进程会执行下一个语句：return studentCollection。

L1中的await等到了L2的return，进而进行下一语句……然而，此时此刻，添加Unknown的M3其实还没有完成。前面看到的残缺的结果就这样被显示了出来。

引入这个问题的原因是，由于在有async关键字的情况下，void或者返回Task都不需要在代码中显式的使用return，我们在改写UpdateNameStudentAsync方法时，没有仔细考虑应当使用void还是Task作为返回类型。因此，到底是返回Task还是保持void是一个在刚开始使用Async时经常遇到的问题。

明白了代码执行流以后，判断方法就不难了：

法则二、当一个方法属于触发后不用理会什么时候完成的方法，可以直接使用void，例如事件处理函数(Event Handler)；
法则三、当虽然不需要返回结果，但却需要知道是否执行完成的方法时，返回一个Task，例如示例中的UpdateNameUnknownStudnetAsync方法。

在把示例中UpdateNameUnknownStudentAsync方法改成如下形式，并且在GetStudentAsync方法中await它以后，我们便可以得到预期的结果了：

   1:          private async Task UpdateNameUnknownStudentAsync(ICollection<Student> studentCollection)

   2:          {

   3:              foreach (var student in studentCollection)

   4:              {

   5:                  await TaskEx.Delay(1000); // Someoperation time like db access or so.

   6:                  student.Name = student.Name ?? "Unknown";

   7:              }

   8:          }

写在最后

Async/await的引入虽然为提供了我们书写异步执行代码的捷径，但是，要用好这把双刃剑，得在理解Async代码的执行流程的基础上不断总结、多练多用啊。

资源下载：

* Sync 版源代码

* Async 版源代码

* Async CTP SP1 Refresh.

本文链接

用WCF + Entity Framework 序列化时的陷阱

2011-07-29T18:06:00Z

当使用WCF + Entity Framework时要小心，否则，很容易掉入各种陷阱。这里介绍两个在序列化时容易遇到的、会导致服务停止的陷阱。

一、试图序列化Entity Proxy类而导致服务停止。

二、序列化时出现死循环导致服务停止；

无论掉入哪一个陷阱，在客户端都会看到这样的对话框(点击看大图)：

呃~这个图才对：

大致意思是会说：服务不在线或者客户端配置有问题或者Proxy类有问题。而如果跟着Error Details里的第一行Google，会找到许多文章关于调整数据缓存大小、调整操作超时时间……如果按照常规则调试方法——按图索骥找问题，那么就可能越陷越深。

查找问题时，首先要透过假象，看到问题的本质——WCF服务因为某些原因而停止了。其次，我们要具体分析问题的特殊性，结合经验，来查找问题。

服务停止有一个典型的原因，那就是序列化出问题了。由于在WCF中，序列化不需要我们写代码实现，它在为我们提供便利的同时，也埋下了伏笔。而EF的使用，又进一步将事情变得错综复杂。凡事有弊有利，往往是使用了EF这样的特殊性，让我们查找问题时也更具方向性。

EF中，有什么特性会与WCF交互？没错，我们常常把EF的实体类用作DataContract。EF的实体类，无论是生成的还是通过Code First写的，运行时，为了支持EF的一些“高级”功能，例如，LazyLoad，Runtime会从你的Entity类自动继承出一个对应的代理类(Proxy Types)并对代理类对象进行操作。例如Person类，在运行时或者就会对应有一个叫Person123456类（肯定不会叫这个名字啦，这权当标识一下）。我们写代码时对Person的操作，运行时会换成对Person123456的操作。

通过调试窗口，我们可以到看到这个隐藏在背后的类（代码类为Handbook，实际类为DynamicProxies.Handbook_AE28…84）：

这样一来，WCF，具体的说，是DataContractSerializer就不认账了——我只认识老子（Handbook），不认识儿子（代理类），没法序列化！于是它抛出了异常，导致服务中断。这样一来，我们会看到，用WCF返回一般的对象没有问题，一旦返回实体类对象，就会遇到了文章开始时看到的错误。

一个简单的解决方法：让DbContext使用静态类。在对应的DbContext的构造函数里添加一个设置即可：

   1:  public partial class MTBContainer : DbContext

   2:      {

   3:          public MTBContainer()

   4:              : base("name=MTBContainer")

   5:          {

   6:              this.Configuration.ProxyCreationEnabled = false; // This is the line added.

   7:          }

   8:          //...

   9:          public IDbSet<PlacePictureType> PlacePictureTypes { get; set; }

  10:          //...

  11:      }

第二个容易遇到的问题是序列化死循环的问题。乍一看错误跟第一个显示的是一样的：服务不可用了！而且同样是序列化问题。

但是，这类问题有一个特别的地方：有些实体类对象能正常返回，有些不能。

经过观察分析发现，不能返回的类往往是那些有Navigation属性的实体类，进一步分析，Navigation属性往往会构成对自身的间接引用：例如在一对多表里，往往一端有一个多端对象的集合，同时，多端又有一个一端的引用。比如有一个Parent实体，有一个Child实体，那么，Parent里会有一个ICollection<Child>用来存储所有的孩子，而Child里又会有一个Parent用来指明当前这个Child的Parent。这种互相引用的关系导致了DataContractSerializer在序列化它时出现了问题。

看来，不光光是在EF中会遇到这样的问题，DataContractSerializer序列化一个直接或者间接引用了自己的类对象，就会陷入死循环。

说话……Visual Studio的图标是不是像一个死循环？^v^

回正题，以上面描述的类为例：

   1:      //[DataContract(IsReference = true)]

   2:      [DataContract]

   3:      public class Parent

   4:      {

   5:          public Parent()

   6:          {

   7:              Children = new List<Child>();

   8:          }

   9:          [DataMember]

  10:          public string Name { get; set; }

  11:          [DataMember]

  12:          public IList<Child> Children { get; set; }

  13:      }

14:

  15:      //[DataContract(IsReference = true)]

  16:      [DataContract]

  17:      public class Child

  18:      {

  19:          [DataMember]

  20:          public string Name { get; set; }

  21:          [DataMember]

  22:          public Parent ParentRef { get; set; }

  23:      }

我们在Console Applicatin的Main函数里试着用DataContractSerializer序列化它：

   1:              // Create mock objects

   2:              Parent p = new Parent() { Name = "Baba" };

   3:              Child c1 = new Child() { Name = "John", ParentRef = p };

   4:              Child c2 = new Child() { Name = "Alice", ParentRef = p };

   5:              p.Children.Add(c1);

   6:              p.Children.Add(c2);

7:

   8:             // Creat DataContractSerializer

   9:              DataContractSerializer serializer = new DataContractSerializer(typeof(Parent));

10:

  11:              // Serialize & output results.

  12:              string result = null;

  13:              using (Stream s = new MemoryStream())

  14:              {

  15:                  serializer.WriteObject(s, p);

  16:                  s.Seek(0, SeekOrigin.Begin);

17:

  18:                  using (StreamReader r = new StreamReader(s))

  19:                  {

  20:                      result = r.ReadToEnd();

  21:                  }

  22:              }

  23:              Console.WriteLine(result);

运行结果是：Crash。默认情况下，DataContractSerializer是这么把对象层层展开：

   1:  <Parent>

   2:     <Children>

   3:         <Child>

   4:             <Parent>    <!—- this is Child.Parent Property… Enter into endless loop -->

   5:                 <Children>

它不会顾及引用关系，只会一味的把对象的属性展成对应的XML元素。因此，Parent –> Child1 –> Parent –> Child1…无穷匮也了。

解决方法一、已经在上面的代码里了：在DataContract上使用IsReference参数，并且设置为true。（[DataContract(IsReference = true)]）。

解决方法二、调用DataContractSerializer的另一个构造函数来替代上面代码中的第9行：

   1:  DataContractSerializer serializer = new DataContractSerializer(typeof(Parent),

   2:          "Parent",

   3:          string.Empty,

   4:          null,

   5:          int.MaxValue,

   6:          false,

   7:          true,

   8:          null,

   9:          null);

第7行用来表明使用Preserve Object Reference。使用了Preserve Object Reference以后，会产生类似以下代码的序列化结果，每个元素都会有其对应的Id，对象引用对引用Id：

   1:  <Parent z:Id="i1" xmlns="http://schemas.datacontract.org/2004/07/Sealize" xmlns:i="http://www.w3.org/2001/XMLSchema-instance" xmlns:z="http://schemas.microsoft.com/2003/10/Serialization/">

   2:      <Children>

   3:          <Child z:Id="i2">

   4:          <Name>John</Name>

   5:          <ParentRef z:Ref="i1"/>

   6:          </Child>

   7:          <Child z:Id="i3">

   8:              <Name>Alice</Name>

   9:              <ParentRef z:Ref="i1"/>

  10:          </Child>

  11:      </Children>

  12:      <Name>Baba</Name>

  13:  </Parent>

WCF的异常信息不准确给问题判断带来了很大的难度。但是，看清问题本质，分析问题的特殊性，加之一定经验的积累，就能很快的找准问题并解决之。

假像总是会露出破绽的。例如，虽然异常信息提示可能是超时，但如果一调用服务马上返回错误，一般就不会是超时问题。如果错误提示说可能数据超过允许返回的大小，那么，试着返回一个单一个对象而非集合……

当然，我们还是在不断努力，希望给大家带来提供更加易用的Visual Studio。

参考资源

Working with POCO Entities

ProxyDataContractResolver Class

本文链接

大家都来搭架构 —— VS 2010 Layer Diagram (层图) 基本使用

2011-07-26T18:40:00Z

Layer Diagram 最早应该出现在TechEd 2008，它不仅可以清晰展示应用程序架构，而且能够为帮助架构师随时检验代码之间的引用关系是否与层图一致，可谓既好看又好用。本文以Visual Studio 2010为例，一步步看来看如何为一个应用程序创建层图并且以此来对应用程序进行校验。

首先来看“好看”的部分，这是我为最近的一个小项目画的层图：

呵呵，我美工功底较差，颜色问题啥的大家凑合一下吧；这个层图“好看”在于：

其一，它把整个解决方案的架构信息清楚的呈现出来了（色块）——从最底下的数据访问，中间的业务逻辑，夹在业务逻辑和ViewModel中间的服务，再到上面的ViewModel和UI，一目了然；

其二，各层之间的依赖关系明确（箭头）——服务层依赖于业务逻辑层，业务逻辑层依赖于数据访问层，这三个层都依赖于实体层，实体层不依赖于任何其它层……

怎么画出来的？以一个最简单的三层架构的代码为例：

创建一个三层架构的项目，或者你敢不敢下载下面的代码试试^v^：

（UI-BLL-DAL）

（由于是下载的代码，VS可能会有安全提示）

点击主菜单Architecture –> New Diagram:

选择“Layer Diagram”，给它取个名字：

此时，VS会要求我们建一个Modeling的项目来容纳层图。

一样，取名，确定就行了。

这样，我们的第一个层图就创建好了——空的啊。

让我们来给它添一些层。首先，从UI开始，点击工具箱里的层，然后，在层图设计器上点击一下，一个层就建好了。双击Layer1，改名叫“UI”。

同样操作，我们为BLL、DAL和Entity建立各自的层。

为层与层之间设置依赖关系。从工具箱选择“依赖”（单向箭头），从UI画向BLL，表示：UI对BLL有直接依赖。同样的方法，让BLL依赖于DAL，这三个层同时依赖于Entity。

接下来，我们就要在层与实体项目之间建立映射。这里有一些选项，我们可以将层映射到文件、Assemblies、命名空间、类等，映射关系的建立也可以通过解决方案浏览器或者架构浏览器来完成。这里这使用架构浏览器为例，在层与命名空间之间建立映射关系。

打开架构浏览器：主菜单 –> Architecture –> Windows –> Architecture Explorer。

点击Class View –> 然后，把Simple3Tier.UI拽到UI层上，这样，我们就把Simple3Tier.UI映射到了UI层上。

这样，我们就可以看到UI层右上角多了一个1，表明它与一个对象形成了映射关系，同时，点击层图上的UI，在右侧的层浏览器（Layer Explorer）中，我们可以看到它到底映射到哪一个对象。

同样，我们把BLL/DAL/Entity分别映射到对应的图形上。我们这样项目的层图就大功告成了：

完成了层图，就可以用来验证应用程序了。让我们右击空白区域，点击“验证架构”。如果你是下载的上文中提供的项目，那么，就应该“中招”了^v^——3个错误：

我们稍微看一下错误信息：看来是因为UI对DAL有依赖。而我们的层图中没有这样的依赖关系——或者不允许这种依赖关系的存在。

因此，至少有两种改法，第一，给层图添加一个依赖关系：从UI到DAL。我想大部分时间我们不会这么做，大家懂的；第二，修改代码。

我们以修改代码为例，双击一行错误，层图会帮助我们定位到代码（Main方法），修改代码如下：

   1:              BizClass bizClass = new BizClass();

   2:              var result = bizClass.GetMessage();

   3:              // DAL.DataClass dataClass = new DAL.DataClass();

   4:              // var result = dataClass.GetMessager().Message;

   5:              System.Console.WriteLine(result);

右击错误，点击“Go to”，选择“层图”。回到层图后，重点右击验证。再看Error List，错误就没有了。

层图可以帮助我们校验代码依赖关系。当代码依赖关系与架构不符时，层图可以帮助我们找到错误代码，以保证整个架构不被破坏。这一点在大型项目多人开发时非常重要。

如果想要在Build时自动进行架构校验，只要修改层图文件的Build Action属性为Validate就可以了。

资源：

Existing Layer Diagrams: Application Architecture Guide Layer Diagrams

Skinner’s Blog: Layer Diagram

MSDN：Layer Diagrams: Guidelines

MSDN: How to: Create Layer Diagrams from Artifacts

本文链接

基于Entity Framework 4.1实现一个适用于单元测试的MockDbContext(下)

2011-07-23T21:13:00Z

上篇中提到，我们在利用修改做的MockDbContext进行单元测试时，在获取数据时出现了问题。原因在于，在写获取的代码时，我们直接调用了DbContext的Set<T>()方法，而这个方法会从数据库中取数据。

我们来看一个例子：

这是一个简化的业务逻辑代码来获取全部的Handbook：

public IList<Handbook> GetMyHandbooks()

var handbookSet = dbContext.Set<Handbook>();

return handbookSet.ToList();

对应的单元测试：

   1:          [TestMethod]

   2:          public void GetMyHandBooksTest()

   3:          {

   4:              var mockDbContext = new MockMTBContainer();

   5:              BizHandbook target = new BizHandbook(mockDbContext);

6:

   7:              mockDbContext.Handbooks1.Add(new Handbook() { HandbookID = 1 });

   8:              mockDbContext.Handbooks1.Add(new Handbook() { HandbookID = 2 });

9:

  10:              var result = target.GetMyHandbooks();

  11:              Assert.IsNotNull(result);

  12:              Assert.AreEqual(2, result.Count);

  13:          }

行4-5创建一个业务逻辑对象，也是我们的测试目标target，第5行中的构造函数以以mockDbContext为参数，此业务逻辑对象会使用mockDbContext而非默认的DbContext。第10行代码调用了GetMyHandbooks()方法。第11行和12行分别验能够获得结果并且结果集中有两个对象。大家已经知道使用上篇中的mockDbContext，这个单元测试会Fail。第12行Assert预期为2，实际为0。

直接问题出在GetMyHandbooks方法的return语句中的.ToList()方法。这是一个System.Linq中提供的扩展方法，它所做的事情是：调用Expression对象进行数据查询得到一个IEnumerator<TEntity>，然后创建一个List<TEntity>对象，进行迭代将数据填入列表，最后返回。谁提供了Expression？DbContext中的DbSet<TEntity>。

在上篇中，我们仅仅是简单的重写了（或者说，废掉了^_^）DbContext的SaveChanges()，但是在查询数据的时候，Expression仍然会从对应的DB中获取数据。另外，对Local属性的理解也有问题，Local里并不是所有数据，但是新增或变更过的数据。于是，单元测试12行出现actual＝0的现象也就得到合理解释了。看来，之前的想法太过简单了。需要重新构思一个mockDbContext。

由于DbSet<TEntity>的Expression属性不是virtual属性，简单重写一下Expression的想法行不通。曾经想过用一个同名属性覆盖它，但是，这样应该也有问题（之所以说应该，是因为没有试过），因为DbContext中使用的都是DbSet<TEntity>类，会调用原来的Expression属性的。

通过以上的分析，我们知道，要让MockDbContext好用，涉及两个类：DbContext和DbSet<TEntity>，因此，现在的思路是，实现两个新的类，替换掉它们。

由于要在业务逻辑不作任何修改的情况下调用DbContext和MockDbContext，这两个类要求实现同一接口；

同理，DbSet<TEntity>和新写的类（叫MockDbSet<TEntity>吧）同样也要实现同一个接口。

我们从MockDbSet<TEntity>着手。由于DbSet<TEntity>实现了IDbSet<TEntity>接口，因此，对于MockDbSet<TEntity>来说，实现IDbSet<TEntity>即可（这个类方法比较多，但都是非常基本的方法，文章最后有下载）：

   1:      public class MockDbSet<TEntity> : IDbSet<TEntity>

   2:          where TEntity : class

   3:      {

   4:          private ObservableCollection<TEntity> storage = new ObservableCollection<TEntity>();

5:

6:

   7:          public TEntity Add(TEntity entity)

   8:          {

   9:              if (entity != null)

  10:              {

  11:                  storage.Add(entity);

  12:              }

  13:              return entity;

  14:          }

15:

  16:          public TEntity Attach(TEntity entity)

  17:          {

  18:              storage.Add(entity);

  19:              return entity;

  20:          }

21:

  22:          public TDerivedEntity Create<TDerivedEntity>() where TDerivedEntity : class, TEntity

  23:          {

  24:              return Activator.CreateInstance<TDerivedEntity>();

  25:          }

26:

  27:          public TEntity Create()

  28:          {

  29:              return Activator.CreateInstance<TEntity>();

  30:          }

31:

  32:          public TEntity Find(params object[] keyValues)

  33:          {

  34:              int currentKeyPropertyIndex;

  35:              foreach (var entity in storage)

  36:              {

  37:                  currentKeyPropertyIndex = 0;

  38:                  foreach (var property in typeof(TEntity).GetProperties())

  39:                  {

  40:                      if (property.Name.Contains("ID"))

  41:                      {

  42:                          if (property.GetValue(entity).Equals(keyValues[currentKeyPropertyIndex]))

  43:                          {

  44:                              currentKeyPropertyIndex++;

  45:                              if (currentKeyPropertyIndex == keyValues.Length)

  46:                              {

  47:                                  return entity;

  48:                              }

  49:                          }

  50:                      }

  51:                  }

  52:              }

  53:              return null;

  54:          }

55:

  56:          public System.Collections.ObjectModel.ObservableCollection<TEntity> Local

  57:          {

  58:              get { return new ObservableCollection<TEntity>(this.storage); }

  59:          }

60:

  61:          public TEntity Remove(TEntity entity)

  62:          {

  63:              storage.Remove(entity);

  64:              return entity;

  65:          }

66:

  67:          public IEnumerator<TEntity> GetEnumerator()

  68:          {

  69:              return this.storage.GetEnumerator();

  70:          }

71:

  72:          System.Collections.IEnumerator System.Collections.IEnumerable.GetEnumerator()

  73:          {

  74:              return this.storage.GetEnumerator();

  75:          }

76:

  77:          public Type ElementType

  78:          {

  79:              get

  80:              {

  81:                  return storage.AsQueryable().ElementType;

  82:              }

  83:          }

84:

  85:          public System.Linq.Expressions.Expression Expression

  86:          {

  87:              get

  88:              {

  89:                  return storage.AsQueryable().Expression;

  90:              }

  91:          }

92:

  93:          public IQueryProvider Provider

  94:          {

  95:              get

  96:              {

  97:                  return storage.AsQueryable().Provider;

  98:              }

  99:          }

 100:      }

延续前文思路，在第4行添加了一个ObservableCollection<T>的集合，用作本地存储；增、删、改全部针对这个集合来完成。第85到91行，在返回Expression的时候，把storage.AsQueryable()的表达式返回出去，这样，查询的的时候就会获取到查询storage中元素的表达式。

接下来，我们要把使用DbSet<TEntity>的DbContext和使用MockDbSet<TEntity>的MockDbContext统一起来。查看一下DbContext……呃~没有实现任何接口-.-||（曾经有位伟人说过……算了，不说了）既然没有接口，我们就来创建一个：

using System.Data.Entity;

namespace MTB.Data

public interface ITestableDbContext

IDbSet<TEntity> Set<TEntity>() where TEntity : class;

int SaveChanges();

这个接口做两件事，第一，可以实现数据持久化——SaveChanges()。第二，可以获取到IDbSet<TEntity>集合以对集合中数据进行操作。然后，做两件事：第一，让具体的DbContext实现这个接口；第二，写一个MockDbContext实现这个接口。
我们先来看DbContext实现接口的部分：

   1:      public partial class MTBContainer : DbContext, ITestableDbContext

   2:      {

   3:          public MTBContainer()

   4:              : base("name=MTBContainer")

   5:          {

   6:          }

7:

   8:          public new IDbSet<TEntity> Set<TEntity>() where TEntity : class

   9:          {

  10:              return base.Set<TEntity>();

  11:          }

12:

  13:          //... Other code...

14:

  15:          public IDbSet<Handbook> Handbooks1 { get; set; }

  16:          public IDbSet<Trip> Trips { get; set; }

  17:          // ... more item

  18:      }

其中，第8到11行，虽然覆盖了Set<TEntity>()，但调用的仍然是DbContext类中的Set<TEntity>()方法；然后把对应的DbSet<TEntity对象集合全部改为IDbSet<TEntity>，大功告成。由于用的是Model First的EF4.1，因此，其实这个类是通过修改模板而来的。修改过的模板会在文章结束时附上。

MockDbContext实现：

   1:      public partial class MockMTBContainer : DbContext, ITestableDbContext

   2:      {

   3:          public MockMTBContainer()

   4:              : base("name=MTBContainer")

   5:          {

   6:              Handbooks1 = new MockDbSet<Handbook>();

   7:              Trips = new MockDbSet<Trip>();

// Other code

  15:          }

16:

  17:          public new IDbSet<TEntity> Set<TEntity>() where TEntity : class

  18:          {

  19:                  foreach (PropertyInfo property in typeof(MockMTBContainer).GetProperties())

  20:                  {

  21:                      if (property.PropertyType == typeof(IDbSet<TEntity>))

  22:                      {

  23:                          return property.GetValue(this, null) as IDbSet<TEntity>;

  24:                      }

  25:                  }

  26:                  throw new Exception("Type collection not found");

  27:          }

28:

  29:          public override int SaveChanges()

  30:          {

  31:              //Do nothing

  32:              return 0;

  33:          }

34:

  35:          // ...

36:

  37:          public IDbSet<Handbook> Handbooks1 { get; set; }

  38:          public IDbSet<Trip> Trips { get; set; }

  39:          // ...

  40:      }

这个MockDbContext同样继承自DbContext类（嗯，可以少写不少代码呢）。但是，覆盖了Set<TEntity>()方法；当然，第29到33行废掉SaveChanges()的事仍然不可不做——如果想让测试更全面一些，看看那些个增、删、改方法有没有忘调用SaveChanges()，利用这个重写设置一个标志为也不错啊

Okay，一切就绪，我们把这一切综合起来使用：

首先，业务逻辑：

   1:      public class BizHandbook

   2:      {

   3:          ITestableDbContext dbContext = null;

4:

   5:          #region Constructions

   6:          public BizHandbook()

   7:              : this(null)

   8:          {

   9:          }

10:

11:

  12:          public BizHandbook(ITestableDbContext dbContextl)

  13:          {

  14:              if (dbContext == null)

  15:              {

  16:                  dbContext = new MTBContainer();

  17:              }

  18:              this.dbContext = dbContext;

  19:          }

  20:          #endregion

21:

  22:          #region Publich Methods

  23:          public IList<Handbook> GetMyHandbooks()

  24:          {

  25:              var handbookSet = dbContext.Set<Handbook>();

  26:              return handbookSet.ToList();

  27:          }

  28:          #endregion

  29:      }

第12行构造函数会要求一个实现了ITestableDbContext的对象，如果为null，那么使用默认的DbContext。增删改查一律该怎么写就怎么写。

测试：

……跟本而第二个代码片段一样，没有变化！（其实，MockDbContext变了）。

Okay，小结时间：

我们创建了一个接口ITestableDbContext，并且写了一个MockDbContext类，来实现对调用EF4.1的业务逻辑代码的单元测试（红的部分）：

模板下载，使用的时候记得修改对应的using和inputFile变量——点击下载。

内容：

1. 使用IDbSet<T>的DbContext的模板；

2. MockDbContext模板；

3. MockDbSet<TEntity>类；

4. ITestableDbContext接口；

对了，顺便提一下，在MockDbSet<TEntity>实现的时候，Find()方法为了方便起见，使用了一个Hack的方法来判断属性是否为Key属性——属性名称中是否含有ID。

本文链接

基于Entity Framework 4.1实现一个适用于测试的MockDbContext(上)

2011-07-22T06:46:00Z

声明：我最近在微软加拿大开发中心工作，这是我个人的博客，跟公司没有关系。如果你在我的博客里看到我推荐微软的产品，就权当广告好了。

我们在作一些CRUD相关的单元测试的时候，通常不会真的连接到数据库，而是写一个Mock的Repository，把Entity放到一个集合啊或者Hash table啊什么的里面。
最近用Entity Framework 4.1写点小项目，在写一个Mock的Repository的时候还走了些弯路，费了一些时间，在此把过程写出来，希望能帮大家节省一点时间。
项目中用的是Model First，在Database First模型中应该也适用，先设计完数据库模型，生成数据库和两个.tt文件——MTBDbContext.Context.tt和MTBDbContext.tt。第一个文件里是一个DbContext类，担任数据持久化操作；第二个文件里是实体类。这两个文件原来与数据库模型是在同一个项目中的，做了一些小动作，把它们分开了^_^。

根据这样的结构，写MockDbContext的思路是这样子的：以添加一个实体类为例，我们通常会写这样的代码：

public void AddBatch(Handbook handbook)

dbContext.Set<Handbook>().Add(handbook);

dbContext.SaveChanges();

如果直接调用EF4.1的DbContext，在调用 DbContext里的SaveChanges()，数据就会被固化到数据库里。但我们相信，只要数据能够在本地保存，通过DbContext，它就一定会存到数据库里，因此，测试时没有必要把数据库写到数据库中去，只要在本地进行验证。
综上，我们需要的MockDbContext只要满足两个条件：第一，SaveChanges()不把数据固化到数据库，而是存在本地；第二，可以在本地作数据验证。
我们首先来满足第一个条件。打开DbContext看一下：

public partial class MTBContainer : DbContext

public MTBContainer()

: base("name=MTBContainer")

protected override void OnModelCreating(DbModelBuilder modelBuilder)

throw new UnintentionalCodeFirstException();

public DbSet<Handbook> Handbooks1 { get; set; }

public DbSet<Trip> Trips { get; set; }

// … more DbSet<T>...

这个类信息不多，因此推测逻辑都在其基类DbContext里。因此，在Object Browser里打开DbContext看了一下：

public class DbContext : IDisposable, IObjectContextAdapter

protected DbContext();

//… more constructors

// Other code ...

public virtual int SaveChanges();

public DbSet<TEntity> Set<TEntity>() where TEntity : class;

public DbSet Set(Type entityType);

//...

里面有一个SaveChanges()方法，而且还是虚的。这样，事情就简单了（起初是这样认为的，也是从这里开始走的弯路）：重写一下SaveChanges()方法，让它什么都不做，它不就不会把数据存回数据库了吗？OK，第一个条件基本达成。

第二个条件，本地验证。由于实体类对象都保存在DbSet<T>里，而DbSet<T>里有一个ObservableCollection<T>类型的Local属性保存的正是本地实体类对象（这个理解有问题的）。这样，事情就好办了，我们写测试验证的时候直接验证这里的结果就行了。

按着这个思路，复制粘贴了一份MTBDbContext.Context.tt，改名为MockMTBDbContext.Context.tt并且放到了对应的单元测试项目中。然后，稍微修改了一下模板：添加了一些using的命名空间，改了生存的类名和构造函数名，然后就是重点添加一个什么都不做的SaveChanges()的重写方法——保存，自动生成代码如下：

...

public partial class MockMTBContainer : DbContext, ITestableDbContext

public MockMTBContainer()

: base("name=MTBContainer")

public override int SaveChanges()

//Do nothing

return 0;

...

public DbSet<Handbook> Handbooks1 { get; set; }

public DbSet<Trip> Trips { get; set; }

…

接下来，就写了一个测试代码来看看一个基本操作：

/// <summary>

///A test for Add

///</summary>

[TestMethod()]

public void AddTest()

var mockDbContext = new MockMTBContainer();

BizHandbook target = new BizHandbook(mockDbContext); // use mockDbContext here.

Handbook handbook = new Handbook();

target.Add(handbook);

Assert.AreEqual<int>(1, mockDbContext.Handbooks1.Local.Count); // see whether the entity object's added

跑Case，成功Pass。哈。没想到这么轻松。

但是…

CRUD四项操作中，CUD都可以测试，R（Retrieve）的时候，却怎么也得不到结果……添加的记录在Local可以看到，但是.ToList()的时候怎么都是null。

＝＝＝＝＝

下篇解释了错误的原因，并且重新设计了一个接口以完成目标。点击继续...

本文链接

利用IProgress轻松搞定进度条编程

2011-07-05T01:09:00Z

毫无疑问，当一个任务需要较长时间才能完成进，如果有一个进度条显示进度，会比简单的显示一个Please Wait要让人感觉好很多。
然而，一旦涉及进度条，那么，程序至少需要同时做两件事（好吧，也许叫异步的做两件事更确切一点）：第一，完成任务本身；第二，计算进度并更新UI。在C# 5.0 Aysnc中提供的IProgress<T>类，为进度条编程提供了便捷的方法。三步即可完成一个简单的进度条。
下面的示例基于Async CTP制作。要能编译、运行示例，需要以下准备：

Visual Studio 2010 SP1.
Async CTP(SP1 Refresh)
一个WPF应用程序，并且有一个进度条，顺便给进度条取个名，例如progressBar之类的 :-)

如果你还不知道Async是什么，点这里。
好了，这样，我们就可以开始示例了。
第一步，写一个类，用于存放参数，我们用这些参数来计算进度。一个最简单的例子就是有两个整数值，一个是当前完成的值，另一个是总值。所以，我们就有了这样一个类：

   1:          //Step 1: Have a class to store current value / total value.

   2:          public class ProgressPartialResult

   3:          {

   4:              public int Current { get; set; }

   5:              public int Total { get; set; }

   6:          }

有些时候，计算进度可能相当的复杂，但是，原则是一样的，把需要的参数全部做在这个类里就行了。当然，也有一种简单的极品：这个类就是一个System.Integer :-)那你就不用自己写了。

第二步，创建一个IProgress<T>的对像，其中，T就是我们刚才创建的类，并且添加相应的处理逻辑，用来处理当进度更新发生时要做的事情。示例中，一旦进度更新，我们就更新UI里的进度条。计算也很简单：当前值/总值*100。

   1:          private void DoProgress()

   2:          {

   3:              //Step 2: Create an object of IProgress<T> to trace the progress & add event handler when new progress reported.

   4:              var progress = new Progress<ProgressPartialResult>();

   5:              progress.ProgressChanged += new ProgressEventHandler<ProgressPartialResult>(progress_ProgressChanged);

6:

   7:              //Step 3: Call async logic with progress report.

   8:              DoSomething(progress);

   9:          }

10:

  11:          void progress_ProgressChanged(object sender, MainWindow.ProgressPartialResult value)

  12:          {

  13:              progressBar.Value = (float)value.Current / value.Total * 100;

  14:          }

好了，我想你已经知道第三步要做什么了：异步完成任务并且汇报进度。

   1:          private async void DoSomething(IProgress<ProgressPartialResult> progress)

   2:          {

   3:              int total = 100;

   4:              for (int i = 0; i <= total; i++)

   5:              {

   6:                  await TaskEx.Delay(20); //Do things for 0.02 seconds.

   7:                  //Report the progress

   8:                  if (progress != null)

   9:                  {

  10:                      progress.Report(new ProgressPartialResult() { Current = i + 1, Total = total });

  11:                  }

  12:              }

  13:              progress.Report(new ProgressPartialResult() { Current = 0, Total = total });

  14:          }

稍微看一下代码，我们假设总量是100，进度for循环以后，首先做任务本身，我们假设每次做0.02秒。然后，就汇报一下进度。当退出循环以后，把进度置为0。

整理一下，整个事情其实是这样的，进度条编程围绕IProgress<T>的对象展开。每当我们在异步的做事的时候，我们就调用Report方法汇报一下进度，进度的参数我们通过一个预先定义好的类来传递。Report()方法会触发ProgressChanged事件，于是，就会调用事件处理者(Handler)逻辑。处理者则根据传递进来的参数，计算出当前的进度，并且做程序员预期它做的事，例如，更新UI上的进度条之类的。

大家可以试一下进度条行进时拖动UI做点别的事玩玩^v^希望本文能够给你带来一些娱乐 :-)

贴个完整的Code Behind。UI部分大家就自行搞定吧。最最后面附简陋的应用程序贴图。

using System;

using System.Threading.Tasks;

using System.Windows;

namespace WpfApplication3

/// <summary>

/// Interaction logic for MainWindow.xaml

/// </summary>

public partial class MainWindow : Window

public MainWindow()

InitializeComponent();

this.DoProgress();

//Step 1: Have a class to store current value / total value.

public class ProgressPartialResult

public int Current { get; set; }

public int Total { get; set; }

private void DoProgress()

//Step 2: Create an object of IProgress<T> to trace the progress & add event handler when new progress reported.

var progress = new Progress<ProgressPartialResult>();

progress.ProgressChanged += new ProgressEventHandler<ProgressPartialResult>(progress_ProgressChanged);

//Step 3: Call async logic with progress report.

DoSomething(progress);

void progress_ProgressChanged(object sender, MainWindow.ProgressPartialResult value)

progressBar.Value = (float)value.Current / value.Total * 100;

private async void DoSomething(IProgress<ProgressPartialResult> progress)

int total = 100;

for (int i = 0; i <= total; i++)

await TaskEx.Delay(20); //Do things for 2 seconds.

//Report the progress

if (progress != null)

progress.Report(new ProgressPartialResult() { Current = i + 1, Total = total });

progress.Report(new ProgressPartialResult() { Current = 0, Total = total });

7/5：关于原文的一点点补充：

前文提到，进度条编程围绕IProress<T>展开。那么，为什么我们需要这个接口，换句话说，IProgress<T>给我们带来了什么？个人的理解如下，如果我们要异步的完成一个任务，例如DoSomething，并且我们已经有一系列函数可以帮且我们完成这个任务了，那么，调用这个函数时，我们可能会接触到以下一些函数的签名：

void DoSomething();

Task DoSomethingAsync();

Task DoSomethingAsync(CancellationToken ct);

Task DoSomethingAsync(CancellationToken ct, IProgress<int> progress);

再如果一下，如果我们想要知道DoSomething的进度，选哪一个会更合理一些？……好吧，每个人都有选择的权力^v^大家自己参？OK。

其实这四个函数就像四个员工，第一个员工闷头干活，什么都不管；第二个会找别人干活，他本身负责协调，适合同一时间多做几件事（好同志啊），但是，一件活他一旦开始做了，天塌下来他也会继续做；第三个员工，跟二个差不多，只是随叫随停；第四个不仅随叫随停，而且，经常汇报进度。

所以，回到IProgress<T>上来，因为有了它，我们调用有它的函数时，虽然不知道执行的细节，仍然可以轻易的知道事态的进度；在写函数时，如果想要提供一个“进度友好”的函数，不管是给自己还是给别人用，把IProgress<T>作为参数都是一个不错的选择。

本文链接