书评——Windows高级调试

调试，是通过尝试运行程序找到问题根源的过程。这和测试不同，测试是发现问题的过程，但不深究问题产生的位置、原因。调试是开发人员必须具备的能力，即便是在分工很细致的大企业中——设计、开发、测试往往由不同的工程师完成——调试这项工作却常常（甚至是必须）由开发人员自己进行。

调试有两个层面，一种是基本调试，是我们每天都在接触的。通常，一个完善的集成开发环境通常都自带有调试器；而如今开发人员的开发习惯，也是写完一段语法完整的代码后就顺手启动调试器调试一下。这类调试通常是特定语言的、源代码级别的、用户态的，对于上层的逻辑错误通常是足够的；但如果遇到更深层次的问题，仅仅通过基本调试就无能为力了。

另一种是高级调试，这种调试通常使用独立的调试器（未与开发环境集成），并能脱离源代码进行调试；甚至可以调试操作系统的底层问题（内核调试）。高级调试并不是开发人员所必需具备的能力（甚至很多开发人员并不熟练掌握高级调试），但掌握高级调试可以大幅提高自身功力，对于开发技术的进阶是必不可少的。

《Windows高级调试》（以下简称《AWD》）一书正是讲解如何在Windows操作系统上进行高级调试的。其实“高级调试”不过是“另一种调试方法”而已，它也有自己的入门、进阶、精通等程度。而《AWD》一书，在老刘看来应该是属于“入门”和“进阶”这两个级别的，特别适合于掌握了一定的开发技术和基本调试技术，想学习高级调试的朋友。

《AWD》分为三部分，第一部分主要介绍高级调试应具备的基本工具，包括调试器和符号文件等。虽然在第一章中介绍了很多种调试器，但整本书用得最多的还是windbg.exe。

第二部分则从实践的角度介绍了多种调试场景，如内存、资源、进程间通信和同步等。这一部分是整本书的核心，细读下来不仅能掌握高级调试的基本方法，还能对操作系统原理有更加深刻的掌握。

第三部分则是高级调试中的高级主题，这一部分内容对于大多数开发人员来说可能并不是必须的，甚至日常工作根本用不到。但对于对调试技术非常着迷的朋友，或者是系统开发者，这部分却是必不可少的。正如Raymond McCollum所说，大多数书籍在涉及到如此高级的主题时，往往“留给读者练习”或“请参阅其他高级参考书”，而本书则属于那些“高级参考书”。

前面提到本书属于“入门”和“进阶”的级别，并非看轻此书。高级调试技术本身就是相对复杂的，但本书却没有故弄玄虚，而是从多种常见的调试场景入手，介绍如何使用调试器来完成特定的调试任务。这样新进入调试领域的开发者就能很快地上手，实际感受到调试的快感和乐趣。而即便是经常使用调试器的熟手，也可以将本书作为参考，快速查找各种场景中的调试命令。

《AWD》一书的遗憾在于，并没有非常详尽地介绍每种调试器，所以读者朋友不得不“参与其他文章或书籍”来掌握各种调试器的基本操作。当然，如果不是这样的话，您手中的书可就不是500余页这么简单了。

（完）

操作无权限的MSMQ队列

首先，我们重现一个这样的“死”队列。在消息队列的管理器中新建一个队列（私有或公有均可），命名为test。右键单击该队列，选择Properties，然后进入Security选项卡，在窗口上部选择Everyone，并在窗口下部的权限列表中，勾选第一行Full Control对应的Deny复选框，最后单击OK按钮。

这样，我们就对所有人禁用了对该队列的一切操作。现在，包括系统管理员在内的任何用户都无法操作该队列，如查看属性或删除队列等操作均无法进行。

解决的方法如下：

打开该目录：C:\Windows\System32\msmq\storage\lqs，对于Vista及以上版本的操作系统，UAC会弹出提示，需要提升权限。因此，该方法要求操作者必须具有管理员权限。

在该目录下可以看到一些以16进制数字命名的文件，其中每个文件都对应着一个消息队列的配置。这些文件都是纯文本文件，可以使用记事本等类似程序打开。其内容类似于：

[Properties]
Type=00000000-0000-0000-0000-000000000000
Instance=e808d736-9552-4e78-8f8e-fbb7710d3005
BasePriority=0
Journal=00
Quota=4294967295
JournalQuota=4294967295
CreateTime=1245907917
ModifyTime=1245907918
QueueName=\test
Label=test
Authenticate=00
PrivLevel=1
Transaction=00
Security=01000480e8280000042...
Signature=MSMQStorage
TimeStamp=cd0b434a

其中的QueueName字段指明了对应队列的路径（名字）。通过遍历每个文件，即可找到我们刚刚建立的test队列。其中的Security字段就是队列的权限配置，其值是一长串16进制数字，这里限于篇幅只截取了前面若干个字符。

因此，不管当前操作者是否真的具有修改队列权限的权限，只需要修改Security字段的值就能修改队列的权限。

我们并不知道这个字段值的实际格式是什么，但可以使用一种取巧地方法——新建一个队列（此时往往具备对该队列进行操作的所有权限），并将新队列的Security字段值复制给当前队列即可。

下面新建一个队列test2，不要修改其属性。再到C:\Windows\System32\msmq\storage\lqs下找到对应于test2队列的文件，将Security字段的值复制下来，并用该值覆盖test队列文件中的字段值即可。

（完）

.assembly a {}
.module a.dll

.field static int32[-268435455...268435456] f_m268435455

保存为a.il。打开Visual Studio的命令行窗口，执行下面的命令，将这段代码编译为a.dll：

ilasm /dll a.il

然后执行下面的命令，尝试用ILDASM打开生成的dll文件：

ildasm a.dll

好了，ILDASM死了：

这是ILASM在处理下标为负数的数组时存在的问题，但也不排除ILDASM自己的问题。

今天先抛出这个问题，改天再撰文分析数组的元数据签名，以及ILASM在这方面的BUG。

注：

1. 上述程序可放心试验，只会影响ildasm.exe一个进程，不用怕机器整个挂掉。

2. 该程序针对.net 2.0~3.5，4.0没有试过，不知道改进了没有。

3. 经仔细思考后发现，这个故障并不仅因为下标为负数，还因为数组的长度过长；如果将上标268435456改小一些，就会发现ILDASM不死了，但得到的下标值是错误的。

一个查看PE文件内容的小工具——CliPeViewer

猛击此链接，下载CliPeViewer：http://files.cnblogs.com/AndersLiu/CliPeViewer.zip

CliPeViewer是老刘编写的一个WinForm小程序，能够用来查看托管PE文件中的各种结构。目前有很多能够查看PE信息的程序，支持.NET的也有。不过，CliPeViewer与他们的最大区别在于，这个小程序更在意原汁原味地暴露一个PE文件中的内容，尤其是对于文件中的每个结构、每个字段，除了显示了它的值之外，还显示出了它在PE文件中的偏移量和原始数据。

坦率地说，CliPeViewer还没有写完。尚欠缺的功能包括：显示IL指令、托管方法的定义（方法头、异常处理块等），以及对元数据签名的解析。之所以放出这个不成熟的版本，是因为老刘等不起了。2005年，老刘就开始学习托管PE文件格式和IL语言，并有想法写这样一个程序，甚至编写了这个程序的最原始版本。

2006年，因为种种原因这件事就放下了。到了2007年，工作之余闲暇时间不少，于是又把这一摊子捡了起来。2008年，老刘惊喜地发现，自.NET 2.0以来，不管CLR怎么进展，编程语言如何进化，但底层的元数据结构似乎一直没发生变化，ECMA-335标准也一直停留在2006年6月的版本。于是老刘发现这件事有搞头，下定决心要搞一搞。

前不久，看了一些C# 4.0的资料，更加坚定了这种看法。C# 4.0里所有的新功能，都是.NET 2.0时代就已经提供了的，只是一直没有在上层语言中体现出来。

从2005年到2009年，不短了，结果一个像样的版本也没写出来。先后开了不下10个项目，名字也改了5、6次了，最后都是不了了之。目前这个CliPeViewer是我最满意的一个版本，也是打算继续跟进下去的版本。老刘觉得不能等了，等到自己满意了，.NET兴许都成历史文物了。

这个程序的代码（NB的多次否定句来了）有够烂，但足够简单，却又很多。所以这里就不放出源代码了，如果实在感兴趣可使用.NET Reflector偷窥。

后面老刘可能会继续修改这个版本，也没准推翻重来。但老刘保证要做的事包括：1）写一个通用点的XML文件，描述PE文件结构，这样大家（包括老刘自己）就可以通过编写代码生成器来生成文件结构的定义了。2）让AndersLiu.CliPe.dll尽可能地为第三方所用。3）写一些文章介绍PE文件格式。

下面截图奉上。

（完）

ReadOnlyDictionary之应用场景

前两天发布了《隐藏接口实现 及 ReadOnlyDictionary》一文，有不少朋友提出疑问。其中一个主要问题就是，这样做真的可以实现“只读”吗？如果还有其他变量引用了ReadOnlyDictionary所包装的普通字典，依然可以通过另外这个变量来修改字典中的内容。有朋友甚至提到了，可以在创建ReadOnlyDictionary时，将原有字典中的内容复制出一份，来做到真正的“只读”。

其实，这些主要是因为我对这个类的应用场景没有介绍清楚的缘故。其实我这里提到的ReadOnlyDictionary也好，.NET提供的ReadOnlyCollection也罢，其目的并不是让整个字典（或集合）真的“只读”，而是希望某些具有字典（或集合）性质类成员，能够做到“在当前类中可读写，在类的外部只读”。

考虑这样一个场景，我要实现一个FileStructure类，表示文件结构，其中包含了多个Field。每个FileStructure里的每个Field都具有不同的名字，我希望用户能够用名字检索到对应的字段，所以最好的方式是将字段保存在一个字典中。

public class FileStructure
{
    public Dictionary<string, Field> Fields
    {
        get { return _fields; }
    }
 
    public FileStructure()
    {
        _fields = new Dictionary<string, Field>();
 
        _fields.Add("DosHeader", new Field(...));
        _fields.Add("PEHeader", new Field(...));
        _fields.Add("OptionalHeader", new Field(...));
    }
 
    private Dictionary<string, Field> _fields;
}

上面的代码虽然保证了Fields属性是只读的——可以确保用户无法用自己的字典实例来替换FileStructure所有的——但却不能防止用户自己向Fields属性中添加其他字段。

如果使用ReadOnlyDictionary，就能很好地避免这一问题。

public class FileStructure
{
    public ReadOnlyDictionary<string, Field> Fields  // Change ‘Dictionary’ to ‘ReadOnlyDictionary’
    {
        get { return _roFields; }  // Change '_fields' to '_roFields'
    }
 
    public FileStructure()
    {
        _fields = new Dictionary<string, Field>();
        _roFields = new ReadOnlyDictionary<string, Field>(_fields);  // Added
 
        _fields.Add("DosHeader", new Field(...));
        _fields.Add("PEHeader", new Field(...));
        _fields.Add("OptionalHeader", new Field(...));
    }
 
    private Dictionary<string, Field> _fields;
    private ReadOnlyDictionary<string, Field> _roFields;  // Added
}

现在，就不怕用户“擅自”修改字典中的内容了。

在ReadOnlyDictionary的实现中，并没有复制所包装的字典中的内容。这样做的好处是显而易见的——其一，节省空间。其二，ReadOnlyDictionary能够及时反映内部普通字典上发生的变化；也就是说，如果在类的“内部”向字典中添加了新值，或修改了某些条目，则在类的“外部”可以从之前拿到的只读字典中，访问到这些变化过的条目。

链接：

• 访问《隐藏接口实现 及 ReadOnlyDictionary》——http://www.cnblogs.com/AndersLiu/archive/2009/04/16/hide-interface-member-and-readonly-dictionary.html
• 下载ReadOnlyDictionary——http://files.cnblogs.com/AndersLiu/ReadOnlyDirectionary.zip

（完）

隐藏接口实现 及 ReadOnlyDictionary

接口代表着一种契约。但有的时候，接口所达成的契约并不适用于全部的场景，或者说，接口可能定义得“太宽了”。这个时候，就有必要隐藏起某些接口成员。

然而，接口既然是一种“契约”，这就要求实现方必须为接口中的所有成员提供实现。所以，这里说到的“隐藏”，是指从对象的视角上隐藏。换言之，就是只有直接在对象上调用成员时，看不到某些接口成员，但如果将对象强制转换为接口类型，依然能看到所有的接口成员。

在C#中，接口的显式实现可以帮助我们实现这一功能。下面的代码可以帮助我们回忆一下接口的显式实现。

public interface IFoo
{
    void Foo();
}

public class Implement : IFoo
{
    // 显式实现的接口成员：
    void IFoo.Foo() { /* 实现 */ }
}

public class Program
{
    static void Main()
    {
        Implement impl = new Implement();
        impl.Foo();  // 编译错误。显式实现的接口成员不能直接在对象上调用。

        IFoo foo = (IFoo)impl;
        foo.Foo();  // 编译正确。
    }
}

下面举个实际的例子。熟悉集合的朋友一定对ICollection<T>接口不陌生。该接口定义了集合类型的一般成员，包括Add、Clear、Contains、CopyTo、GetEnumerator、Remove、Count等等。从集合的角度来看，这些成员是很充分的。

但是，考虑这样一个场景——希望实现一个只读集合类，这个类不允许改变集合的内容。很明显，只读集合也“是一个”集合，所以理应实现ICollection<T>接口。然而，接口中的Add、Clear和Remove等方法无疑是破坏了集合的“只读”特征。

因此，在实现只读集合时，可以用这样一种方式来实现只读集合类——在类型中定义一个普通集合类型的私有字段，也就是说，让只读集合“包装”一个普通集合。这个只读集合类依然实现ICollection<T>接口，其中不会破坏“只读”性质的成员，直接采用普通集合的实现；而对于会破坏“只读”性质的接口成员，则采用显式接口实现的方式，从对象实例中隐藏掉该成员。

最后，为了防止用户将对象强制转换为接口类型，并试图调用那些会破坏只读性质的成员，需要在这些成员的实现代码中抛出异常（推荐使用NotSupportedException异常）。

例如，下面介绍一个ReadOnlyCollection类：

首先，令该类实现ICollection<T>接口，定义一个私有字段存放待包装的普通集合，并在构造器中为其赋值。

public class ReadOnlyCollection<T> : ICollection<T>
{
    private ICollection<T> _collection;

    public ReadOnlyCollection<ICollection<T> collection)
    {
        if(collection == null)
            throw new NotSupportedException();

        _collection = collection;
    }
}

对于那些不会破坏只读性质的成员，直接利用普通集合的实现即可。这里以Contains方法为例。

public bool Contains(T value)
{
    return _collection.Contains(value);
}

而对于那些会破坏只读性质的成员，则采用接口成员的显式实现，并在实现代码中抛出异常。这里以Add方法为例。

void ICollection<T>.Add(T value)
{
    throw new NotSupportedException();
}

非常cool的是，.NET从2.0开始，已经为我们提供了这样一个只读集合，位于System.Collections.ObjectModel命名空间中。

当然，这里为了能够简单地说明问题，提供的代码示例与.NET中的实现并不太一样，有兴趣的朋友可以用.NET Reflector查看ReadOnlyCollection<T>类的源代码。

遗憾的是，.NET只为我们提供了只读集合，却没有提供只读字典（或者是提供了，但我不知道）。所以在这里我仿照ReadOnlyCollection<T>类，编写了一个ReadOnlyDictionary<TKey, TValue>类。代码略长，这里就不贴了，感兴趣的朋友可以通过下面的链接下载：

http://files.cnblogs.com/AndersLiu/ReadOnlyDirectionary.zip

书评——《Microsft .NET Framework 3.5 – Windows Forms Application Development》

《Microsft .NET Framework 3.5 – Windows Forms Application Development》（以下简称《WinForm》）本身是一本考试用书（Training Kit, MCTS EXAM 70-505）。因此，对于希望学习Windows Forms编程的朋友来说，这本书比市面上其他WinForm类技术图书效果更好一些。

考试用书最大的特征就是直入主题、开门见山。所以从第一章开始你就将学习到WinForm的核心技术，而不是所谓的“背景”啊、“简介”啊什么的。所以，这本700余页的书含金量还是很高的。

《WinForm》这本书不仅是一本介绍技术的书，还介绍了不少技巧。比如第一章，除了介绍了窗体的各种属性之外，还介绍了非矩形窗体。这是很难能可贵的，因为一般考试用书或官方书籍，往往都会偏重技术而忽略技巧；而在实际的开发工作中，往往技巧要比技术更管用。

《WinForm》一书总结起来就一个字——全。WinForm领域能想到的，这本书全有。窗体、使用基本的Windows控件、创建自己的控件、打印、拖拽、异步、数据访问，应有尽有。对于初学者来说，本书可以建立一个全面的知识体系；而即便是WinForm老手，也难免有一些技术是自己鲜有涉足的地方，则更可以把这本书当作一部参考，用到时随手翻来。

可能有些朋友比较迷惑，WinForm编程，不就是拖拖鼠标吗？用得着看书学习么？呵呵，小拖拽里有大学问，有的时候，操作上的一个小偏差，可能会带来意想不到的问题。《WinForm》一书还有一个特征就是对操作的介绍很详实，该选择哪个菜单项、点击那个位置，都一一有所说明。此外，这本书还提供了大量的屏幕截图，更加直观地展示了应作的操作和操作的结果。

唯一遗憾的就是，这么全面的一本书只介绍了从初级到中高级的技术技巧，而不涉及高级技巧。比如在使用异步的时候，会有很多值得注意的地方；打印控制、自定义控件等等，背后都还有很多更有价值的话题，而这些主题往往很难从第三方的技术图书或技术文章中获取。

最后，本书有一点名不副实的地方就是挂了个“.NET Framework 3.5”的名头。事实上，WinForm到了.NET 2.0之后也就基本定型了，.NET 3.0之后微软开始大力发展WPF。所以本书介绍的知识和技术，应该是2.0就开始使用的了——换言之，如果你一直在用2.0（可能没有条件或没有欲望换成3.5），那么依然可以使用这本书学习WinForm，不用担心“.NET 3.5太新了”。

（完）

[翻译] Aggregator Provider模式——白皮书

Definition
定义

Aggregator Provider Pattern is an extension of Provider Pattern, which enables us to create and utilize multiple instance of the class having the same provider interface. In this pattern, there is an Aggregator class which implements the provider interface and contains a collection of instances of classes having the same provider interface.

Aggregator Provider Pattern是Provider Pattern的一种扩展，用于创建和利用多个具有相同提供器接口的类的实例。该模式有一个Aggregator类实现了提供器接口，并包含了一系列实现了相同提供器接口的类的实例集合。

The underlying caller class of this aggregator is simply unaware of how many provider instances do the caller Provider Aggregator contains, but all of the provider instances will be utilized with a single invocation from the caller class.

这个聚合器的潜在调用方类并不知道Provider Aggregator中包含多少个提供器实例，但在调用方类发起的一次调用中，所有的提供器实例都会被调用到。

Comparison with Provider Pattern
与Provider Pattern的比较

Provider Aggregator Pattern is fully compatible with the existing Provider Pattern and the power of provider pattern can be easily extended to use multiple providers concurrently without any modification on the caller classes that were using a provider.

Provider Aggregator Pattern与现有的Provider Pattern完全兼容，而且Provider Pattern的功能可以很方便地扩展到同时使用多个提供器，而无需对使用提供器的调用方进行任何修改。

In short Provider Pattern is concerned with the utilization of one of the available providers; whereas Aggregator Provider Pattern is concerned with the utilization of all of the available providers at the same time.

简单来说，Provider Pattern考虑的是如何调用可用的提供器中的某一个，而Aggregator Provider Pattern考虑的是如何同时调用所有可用的提供器。

Example Demonstration
示例演示

Aggregator Provider Pattern is useful when we need a configurable framework to add/remove multiple services used by one caller/user. For instance we can have Logger Provider framework, where we need log info to be saved at text files, save to database and sent to email addresses and so on. Having an easy configurable framework along with Aggregator Provider Pattern will enable us to add or remove more services without requiring the code modification in the code that uses this provider.

当我们需要一个可配置的框架，用于为调用方/用户添加/移除多种服务时，就可以使用Aggregator Provider Pattern。例如我们有一个Logger Provider框架，我们需要将日志信息保存到文本文件、保存到数据库并向指定的地址发送email。具有一个一个应用了Aggregator Provider的简单可配置框架，我们可以添加或移除更多的服务，而无需修改使用该提供器的代码。

Regarding the example case that just been described can utilize the Aggregator Provider Pattern, by creating the classes as illustrated above. The code snippet below shows a basic usage of this pattern, where the last line will perform the log operation based in list of log providers loaded in the aggregator class dynamically.

上面通过创建类图的方式描绘了一个案例。下面给出的代码片段给出了该模式的基本使用方式，最后一行代码基于在聚合器类中动态加载的一系列提供器执行了log操作。

（完）

后记

我在最近的一个项目中使用了Provider模式，恰好也是日志相关的，我遇到了同样的问题——需要将日志同时放入文本文件、数据库和系统的EventLog中。这时，传统的Provider模式的确难以满足需求，不过我的解决方案很简单——从配置文件中加载所有的Provider，放在一个集合里，然后每次需要记录日志时，遍历集合中的所有Provider，完成调用。

后来我想到了Façade模式，仿照Façade的思想，写了一个方法来协助我遍历这个集合。然后代码就这样固定下来了。

现在想想，那个辅助方法的签名，不是喝Provider接口中的方法签名一样么？如果能多走一步，不就得到了这里所说的Aggregator Provider模式了么？

不过，就算这样做了又如何？我能认为我发现了一种新模式么？

就算我认为发现了一种新模式又如何？会有人认同么？因为这实在是太简单了，当大家遇到类似问题时，多想一下一定会发现这种模式的。如果这样一篇文章直接出现在博客园的首页，恐怕负面评论要多过正面的。

中国人是聪明、勤劳的，模仿能力和举一反三的能力都很强，但却缺乏创新。为什么会缺乏创新呢？我认为是缺乏被认可。

所以借这个机会，我想呼吁博客园的各位专家牛人和粪青达人，从我做起，做到“认可”先。希望不管首页出现多么“新手”、“小白”、“不自知之明”的文章，我们都应首先做到鼓励。要知道这也许是一个新人创新的开始，一个“建议发到新手区”或者“这样的文章也上首页”，也许就浇灭了一朵创新的火种。

（完，这次是真的完）

[翻译] Anders Hejlsberg访谈录——Geek of the Week

Anders Hejlsberg, the creative genius behind C#, and much of the .NET framework, had already been famous for sixteen years as a compiler-writer before he joined Microsoft twelve years ago. His BLS Pascal, Turbo Pascal, and Delphi had revolutionized the way that we develop software. Today, he is still bubbling with new ideas and radical initiatives.

Anders Hejlsberg，C#和.NET框架背后的创造型天才，在12年前加入微软之前，他就以编译器编写者的身份驰名16年了。他的BLS Pascal、Turbo Pascal和Delphi彻底变革了软件开发方式。今天，他依然能够冒出新的想法和激进的倡议。

Whether he truly is an international superhero of C# as some claim, Anders Hejlsberg is certainly a visionary. Known as one of the 'big brains' at Microsoft, he was born in Copenhagen in Denmark and studied engineering at the Technical University of Denmark in Lyngby.

不管他是否像人们声称的那样是C#的国际化超级英雄，Anders Hejlsberg绝对是一个幻想家。作为微软“大脑”之一的他，出生在Denmark（丹麦）的Copenhagen（哥本哈根），并在位于Lyngby的Technical University of Denmark学习了工程师。

It was here that Anders began writing programs for the Nascom microcomputer including a Pascal compiler for CP/M and MS-DOS and marketed for the Nascom 2, under the name Blue Label Software Pascal, or BLS Pascal. Later he went to work for Borland and rewrote his compiler to become Turbo Pascal for the IBM PC. This new compiler sold for $49.95, which was far cheaper than any other commercial high-level language. It became hugely popular in the 1980s thanks in part to an aggressive pricing strategy and having one of the first full-screen IDEs. It became popular with hobbyists as a structured replacement for BASIC. This was followed by 'Super Pascal' which had labels, a return statement and expressions as names of types.

在这里Anders开始为Nascom微型计算机编写程序，包括一个针对CP/M和MS-DOS的Pascal编译器，和针对Nascom 2销售的名为Blue Label Software Pascal的编译器，亦称BLS Pascal。之后他去Borland参加工作，并编写了自己的编译器，这款编译器最终变成了针对IBM PC的Turbo Pascal。这款新型编译器售价$49.95，比当时任何其他商用高级语言编译器都要便宜很多。这款编译器在二十世纪80年代非常流行，很大程度上是因为这种盛气凌人的价格策略，以及其具备的首个全屏幕IDE。它深受初学者喜爱，并成为了BASIC的替代品。这之后是Super Pascal，它具备标签、返回语句和类型名字表达式。

Anders' Turbo Pascal version 5.5 finally added object orientation to Pascal, but the Object-oriented culture was in full swing, and so Anders and his team used Apple's draft standard for Object Pascal to create Delphi with a reference-based object model, virtual constructors and destructors, and properties. Delphi is still used to this day to produce high-quality commercial software.

Anders的Turbo Pascal 5.5版最终为Pascal添加了面向对象，但此时面向对象的文化已经全面地铺开了，因此Anders和他的团队使用了Apple关于Object Pascal的标准草案来创建Delphi，包括一个基于引用的对象模型、虚构造器和析构器以及属性。今天人们依然在使用Delphi生产高质量的商业软件。

Anders joined Microsoft in 1996 and was architect for the Visual J++ development system and the Windows Foundation Classes (WFC). The WFC was primarily designed for creating GUIs for Java applications on Windows. J++ was close to Java, but differed in important aspects. A dispute with Sun over this was settled when Microsoft agreed not to advance J++ beyond its mirrored implementation of Java, version 1.1.4. The technology of J++ was eventually recycled, and survived for a while, as part of the Microsoft .NET platform and the J# programming language.

Anders于1996年加入Microsoft，担任Visual J++开发系统和Windows Foundation Classes（WFC）的架构师。WFC主要设计用于使用Java来为Windows应用程序创建GUI。J++很贴近Java，但在关键方面有所不同。为此Microsoft和Sun产生了争执，而最终以Microsoft同意不再发展J++使其超越对应的Java实现——版本1.1.4——而告终。J++的技术最终被回收，并作为Microsoft .NET平台的一部分和J#编程语言的形式得以暂时存在。

Anders was rapidly promoted to Distinguished Engineer in 2000. He is now a Technical Fellow in the Developer Division and chief designer of the C# programming language and a key participant in the development of the Microsoft .NET framework.

很快Anders在2000年被提升为Distinguished Engineer。他现在是Developer Division的Technical Fellow和C#编程语言的首席设计师以及Microsoft .NET Framework开发团队中的关键成员。

Since its initial release in 2000, the C# programming language has been widely adopted and is now standardized by ECMA and ISO.

自从2000年首次发布以来，C#编程语言得到了广泛应用，并已被ECMA和ISO组织纳为标准。

He has co-authored "The C# Programming Language", published by Addison Wesley, and has received numerous software patents. In 2001, he was the recipient of the prestigious Dr. Dobbs Excellence in Programming Award.

他还是《The C# Programming Language》（Addison Wesley出版）一书的合著者，并且获得了多项软件专利。在2001年，他还获得了最有威信的Dr. Dobbs Excellence in Programming Award奖项。

RM:

"Anders, why is C# called C#. Wasn't it originally named Cool? There's a rumour going around that it was renamed because of the desire to attract geeks. I jest of course, but why the name change?"

“Anders，为什么C#叫做C#？最初它不是叫Cool么？有传闻说它改名是为了吸引极客（Geek）的注意。当然了，我是在开玩笑，但为什么要改名呢？”

AH:

"Yes, the codename for C# was COOL, which stood for C-style Object Oriented Language. We actually liked that name and even looked at keeping it for the final product, but the trademark lawyers weren't, um, cool with it. So, we had to convene the language naming committee. We wanted to have a reference to the language's C heritage in the name and finally settled on C#. Some other candidates I recall were e-C, Safe C, C-square, C-cube, C-prime, C-star, and Cesium... Looking and those now I'm pretty happy with our choice."

“是的，C#的研发代号就是COOL，表示C-style Object Oriented Language。我们非常喜欢这个名字，并且非常希望能够将其用在最终的产品中，但是商标法不允许，嗯，它太酷了。所以，我们必须召开语言命名委员会会议。我们希望语言的名字能够体现出C的传统，于是最终敲定为C#。其他一些我能回忆起来的候选名字还有e-C、Safe C、C-square、C-cube、C-prime、C-star和Cesium……回忆起这些，我现在还是为我们的选择感到高兴。”

RM:

"What were the fundamental flaws in other languages that you believe drove the development of Common Language Runtime (CLR), and in turn, C#?"

“你认为其他语言中的哪些本质上的缺陷驱动着CLR和C#的开发？”

AH:

"I wouldn’t say we were motivated by fundamental flaws in other languages. It was more that we needed to modernize the Windows developer experience. At the time we had multiple distinct development toolsets, e.g. Visual Basic for Rapid Application Development, C++/MFC for systems-level programming, VBScript and IIS for Web applications, and so on. There was little or no sharing of code and skills between these toolsets and your application model would effectively dictate a particular programming language. Furthermore, application interoperability was done through COM, which is a very low-level mechanism, programmers often had to do explicit memory management, there was no common exception and error handling mechanisms, etc. etc. We wanted to fix all of those issues by creating a unified programming platform that supported multiple programming languages, was object-oriented at the core, and provided a shared API framework with modern services such as garbage collection and exception handling."

“我们并不以其他语言中的本质缺陷为动机。我们更多是为了给Windows开发人员提供更加现代化的体验。那个时候我们拥有很多不同的开发工具集，如用于快速应用程序开发的Visual Basic、用于系统级编程的C++/MFC、用于Web应用程序的VBScript和IIS等等。在这些工具集之间，很少甚至没有代码和经验能够共享，而且你的应用程序模型往往是受特定的编程语言支配的。另外，应用程序的互操作是通过COM进行的，这是一种非常底层的机制，程序员通常必须进行显式的内存管理，也没有通用的异常和错误处理机制，等等等等。我们希望创建一个统一的编程平台来解决这些问题，这样一个平台应该能够支持多种编程语言、以面向对象为核心，并能提供一个共享的API框架以及流行的服务，如垃圾收集和异常处理。”

RM:

"There's no real concept of inner classes in C#--you can declare a class inside another class, but it's not really the same as an inner class in Java, unless you're talking about those declared static. Did you consider introducing them when you were designing the language? if so why did you reject them?"

“在C#中没有真正的内部类的概念——你可以在另一个类中声明一个类，但这并不是像Java中那样的真正的内部类，除非你将它声明为静态的。在你设计这个语言的时候，你考虑过加入这个概念吗？如果考虑过，你为什么又放弃了呢？”

AH:

"Correct, C#'s nested classes do not implicitly carry a reference to an instance of the enclosing class, so in Java terms they are like static inner classes. C#'s view is that nesting of classes is just a way to control lexical scoping. If you need to, it takes but a line or two of code to store a reference to an outer class instance in a nested class, so you can pretty easily emulate Java's inner classes.

“是的，C#的嵌套类并不隐式地携带一个指向包装类实例的引用，所以从Java的角度看，这更像是静态的内部类。C#认为类的嵌套只是一种控制词法作用域的途径。如果你需要的话，可以通过一两行代码在包装类示例中存放一个嵌套类的实例，因此你可以非常简单地模拟出Java的内部类。

I think a much bigger difference is C#'s support of lambda expressions and closures, both cornerstones of functional programming. These are still missing from Java, although there have been multiple proposals to add them. In terms of expressiveness I think these are far more important than inner classes."

我想还有一个巨大的区别在于C#对lambda表达式和闭包的支持，这都是函数式编程的基石。但Java依然没有加入这些特性，即便有很多提议要求添加。从表现力的角度来说，我认为这些远比内部类更重要。”

RM:

"I've noticed that the event registration/un-registration thread is unsafe? Why is that?"

“我注意到事件的注册/取消注册不是线程安全的，这是为什么？”

AH:

"No, that's not the case. If you declare an event without explicitly implementing the add and remove accessors (the C# language specification uses the term "field-like event" for this), the C# compiler automatically generates thread-safe accessors for you.

“不，并不是这样的。如果你在声明一个事件时没有显式实现其add和remove访问器（C#语言规范使用‘类似于字段的事件’这种语法），C#编译器会自动为你生成线程安全的访问器。

Perhaps what you are referring to is that you must take extra care when writing thread safe code that raises events. For example, say you have a class that declares and raises an EngineFlameout event:

你所提到的问题，可能是在编写线程安全的用于触发事件的代码时需要格外主义的问题。例如，假设你有一个类，声明并触发了一个EngineFlameout事件：

public class RetroRocket
{
    public event EventHandler EngineFlameout;

    protected virtual void OnEngineFlameout(EventArgs e) {
        if (EngineFlameout != null) EngineFlameout(this, e);
    } 
}

This code looks innocent enough, but it isn't thread safe. Specifically, a race condition arises when another thread unsubscribes to the EngineFlameout in the short period of time between the null check and the invocation of the event handler—the event might then become null and an exception would occur. The code can be made thread safe by first copying the event delegate into a local variable, i.e.

这段代码看上去有够简单，但它并不是线程安全的。尤其是，当在null检查和调用事件处理器之间的这一小段时间里，如果其他线程取消注册EngineFlameout事件，就会产生竞态条件——此时事件可能是null，并且会抛出一个异常。只要首先将事件委托复制到一个局部变量中，就能让这段代码变成线程安全的，例如：

protected virtual void OnEngineFlameout(EventArgs e){
    var handler = EngineFlameout; 
    if (handler != null) handler(this, e); 
}

This is really no different from code that tests whether an object reference is null before calling a method on the object, it just so happens that we're dealing with events here. As with literally any piece of code written in an imperative programming language, extra work is required to ensure thread safety."

对于任何首先检查对象是否为null，再在对象上调用方法的代码而言都是这样，处理事件时也不例外。事实上，任何使用命令式编程语言编写的代码，都需要做额外的工作才能确保线程安全。”

RM:

"It's probably more of a CLR issue, but why doesn't the "throw" statement work as advertised? It always resets the stack trace even if used without an argument "

“这个可能是CLR的一个大问题，为什么‘throw’语句不像宣称的那样工作？它总是重置堆栈跟踪，即便在使用的时候没有携带参数。”

AH:

"If you "throw" without an argument (known as a rethrow), the StackTrace property of the exception is not reset. That is one of the main differences between the implicit and explicit forms of the "throw" statement. That said, the CPU stack is always unwound upon entry to a catch block, even if that catch block rethrows the exception or throws another exception. This might be the issue you are referring to. It is a natural effect of the CLR's exception handling being built on top of Windows Structured Exception Handling (SEH). A team mate of mine, Mike Stall, has a good blog post on this topic:

“如果你在‘throw’的时候没有携带参数（称作rethrow），异常的StackTrace属性是不会重置的。这是隐式和显式形成‘throw’语句之间的主要差别之一。这就是说，在进入一个catch块的时刻，CPU堆栈永远都是未展开的，即便catch块rethrow了该异常或throw了另一个异常。这可能就是你所提到的问题。这是CLR异常处理的本质特征，因为它是构建在Windows结构化异常处理（SEH）之上的。我的一个团队成员Mike Stall写了一篇有关这个主题的不错的blog：

http://blogs.msdn.com/jmstall/archive/2007/02/07/catch-rethrow.aspx”

RM:

"When you want to hack up an experiment quickly, do you use C#? if not, what do you use?"

“当你需要做一个快速实验时，你会使用C#吗？如果不使用C#，你会用什么？”

AH:

"Well, I pretty much do all my experimentation in C#. Dogfooding is important!"

“嗯，我的几乎所有试验都是用C#做的。狗食是很重要的！”

RM:

"How do you think the introduction of the new "dynamic" type in C# 4.0 will affect application performance and reliability?"

“你如何看待C# 4.0中新引入的‘dynamic’类型？它会对应用程序的性能和可靠性带来哪些影响？”

AH:

"The "dynamic" type in C# 4.0 makes it much, much easier to interface with anything for which you do not have a static .NET type—for example, COM and OLE Automation libraries, the JavaScript and HTML object models, objects from dynamic languages such as Python and Ruby, or REST based Web Services. Where you would previously have to go through reflection-like APIs, such as Type.InvokeMember and ScriptObject.Invoke, you can now just write regular methods calls that are resolved dynamically at run-time.

“C# 4.0中的‘dynamic’类型极大地简化了与其他不具备静态.NET类型的系统之间的接口——如COM和OLE Automation库、JavaScript和HTML对象模型、来自动态语言如Python和Ruby的对象或基于REST的Web Services。之前你必须使用反射风格的API，如Type.InvokeMember和ScriptObject.Invoke，而现在你只需要编写常规的方法调用，而在运行时对其进行动态解析。

C# 4.0 really is a happy marriage of static and dynamic programming—instead of picking one or the other, you get to do both in the same programming language.

C# 4.0真的是静态和动态编程之间完美的联姻——不用破坏其中的任何一方，两者都能用同一种编程语言来实现。

I expect performance and reliability to both benefit. Similar to IronPython and IronRuby, C# 4.0 uses the Dynamic Language Runtime (DLR) for all dynamic dispatch, and the DLR has been extensively tuned to provide great performance."

我认为这对性能和可靠性方面都有益处。和IronPython和IronRuby类似，C# 4.0使用动态语言运行时（DLR）进行所有的动态分派，而DLR经过了大量的微调，可以提供卓越的性能。”

RM:

"By the time .NET came on the scene, Java had already been around for a number of years as a successful managed platform, and whilst there are obvious similarities between C# and Java, there are also some differences. When designing the C# programming language, what did you learn from the Java experience, and were there any shortcomings in that language that you tried to avoid?"

“在.NET走上历史舞台的时候，Java作为一款成功的托管平台已经风光了好几年了。而C#和Java之间有很多明显类似的地方，也有很多不同。在设计C#编程语言时，你从Java中借鉴了哪些经验，又有哪些不足是你需要努力避免的？”

AH:

"Well, Java certainly demonstrated the value of type safety, exception handling, and garbage collection in a mainstream programming language. Those just do wonders for productivity.

“嗯，Java的确展示出了再主流编程语言中，类型安全、异常处理和垃圾收集的巨大价值。这些都是生产力方面的奇迹。

Many programming languages influenced C#. Java was one of them, but C++ and Delphi also influenced our design. If I had to call out a few of the differences between C# and Java from a programming language point of view, I might mention C#'s unified type system (value types, boxing, and unboxing), first class support for properties and events, delegate types, separation of logical naming and physical packaging, and unsafe code.

C#受到很多编程语言的影响。Java正是其中之一，但C++和Delphi也影响了我们的设计。如果非要从编程语言的角度说出C#和Java之间的区别，我认为这就是C#的统一类型系统（值类型、装箱和拆箱），对类的一流支持，包括属性和事件、委托类型、逻辑名字和物理打包之间的分离、以及不安全代码。

Also, C# and .NET's design for generics doesn't rely on erasure but rather has true representation of type parameters at run-time. I think this brings about many important advantages. And, of course, in C# 3.0 we introduced Language Integrated Query (LINQ) which really has no counterpart in Java."

另外，C#和.NET对泛型的支持并不依赖于擦除，而是对运行时类型参数的真实体现。我想这会带来很多优点。当然，在C# 3.0中我们还引入了语言集成查询（LINQ），这在Java中绝对没有对应的特性。”

RM:

"Do you believe the LINQ query comprehension syntax (is this its official name?) is a successful feature, or more of an interesting experiment?"

“你认为LINQ查询内涵语法（这是官方的名字吗？）是一种成功的特性，还是更多只是一种有趣的实验？”

AH:

"We call them "Query Expressions" in the language reference, and, yes, I absolutely consider them a successful feature. The fact that you can write your queries in a high-level SQL-like syntax is incredibly important to a lot of programmers. It makes the feature much more approachable. Yet, because the compiler simply turns queries into sequences of method calls with lambda expression arguments, we get a great extensibility story.

“在语言参考中我们称之为‘查询表达式’，我绝对认为这是一种成功的特性。实际上可以用高级的类似于SQL的语法来编写查询，对很多程序员来说出乎意料的重要。这使得这种特性更加贴近开发者。而且，因为编译器只是简单地将查询转变为一系列对携带lambda表达式参数的方法调用，所以我们能得到强大的可扩展性。

When I talk to C# or VB.NET programmers now, most of them use LINQ in their day to day coding, be it LINQ to Objects, LINQ to XML, LINQ to SQL, the Entity Framework, or one of the many third party LINQ providers. And if they don't, it is usually more a question of downlevel deployment than usefulness of the feature. The ability to query in-memory objects, XML, and relational data with a single unified syntax is just really compelling."

现在，在我和C#或VB.NET程序员聊天时，发现他们中的大多数都在每天的编程工作中使用LINQ，他们使用LINQ to Objects、LINQ to XML、LINQ to SQL、Entity Framework或者很多第三方LINQ提供程序。如果他们不使用LINQ，在降级部署时就会遇到比使用该特性更多的问题。使用单一统一语法来查询内存中对象、XML和关系型数据的这种能力，是确实可以通过编译的。”

RM:

"Nemerle showed that adding meta-programming support to C# was a serious possibility? Have you ever considered it?"

“Nemerle表明在C#中添加元编程支持是很有可能的？你考虑过这一点吗？”

AH:

"It is one of the directions we are looking at for future versions of C#. Indeed, I see meta-programming as a piece of our bigger "Compiler as a Service" theme that we are working on for a future release. We want to open up our compiler so it becomes an API you can call to compile a piece of code and get back expression trees and/or IL. This enables a whole host of scenarios, such as application programmability, an interactive prompt, user-written refactorings, and domain specific languages that have little islands of C# imbedded in them."

“这是我们所关注的C#未来版本的一个发展方向。确实，我认为元编程是我们‘编译器即服务’这个庞大主题中的一部分，我们正在为他的发布进行着努力。我们希望开放编译器，使其成为一个API，你可以调用这个API来编译代码片段，并得到表达式树和/或IL。这实现了一种完全宿主的场景，如应用程序可编程性、交互式提示符、用户编写的重构和领域特定语言，所有这些都可以提供一小块地方将C#嵌入进去。

（完）

下面是老刘写的一个类库中的一个类：

其中的常量Version表示类库的当前版本，而方法GetVersion会给出描述当前版本的字符串。用下面的命令行可以将其编译为一个DLL：

接下来，一个倒霉的家伙从老刘这买了这个类库，写了自己的程序：

这个家伙用下面的命令行编译了自己的程序：

运行程序，一切正常，屏幕显示出预期的结果：

过了两天，老刘升级代码了。都升级哪些部分了呢？把Version的值改成2了，然后重新编译了Library。所以代码就不贴了。前面这个家伙因为很乖，从老刘这里买了正版，所以老刘承诺免费升级50次，因此他拿到了新版的Library.dll。

当这个家伙再跑自己的程序（注意他没有重新编译自己的代码），问题来了：

我们看到，通过常量访问得到的版本依然是1，而通过类库方法得到的版本字符串是2。

这是怎么回事呢？让我们祭出ILDasm，看一下Version常量的定义：

Version定义中的关键字literal表明，这是一个字面常量值。“字面”意味着其值将被直接编译到IL代码中，而不会保留对这个常量的引用。

因此，当我们看到Program.cs中Main方法的IL代码后，就不那么吃惊了：

我们可以看到，这里根本没有Version这个常量的影子。只有IL_0006: ldc.i4.1这一行直接加载了数值1——在编译Program的时候，类库中Version常量的值。

有朋友可能想说，那重新编译一下Program不就解决问题了？可问题在于，.NET的一个重要原则就是部署容易和消除DLL陷阱。不能强制要求客户在类库升级后还要重新编译自己的程序。

所以，对于类库设计人员来说，当暴露一个公开的常量时要非常小心，只有确信一个值永远不会发生变化（包括今后的一系列升级）时，才能使用常量。否则请使用只读（只有get访问器）属性或只读（readonly）字段来返回这样的值。

之前我们介绍了在switch语句中使用整数类型和枚举类型的情况。这一部分继续介绍使用string类型的情况。string类型是switch语句接受的唯一一种引用类型参数。

下面来看一段C#代码。

代码1展示的方法中只有一个switch语句，它接收一个字符串类型的参数s，并根据6种不同的情况显示不同的文字。它将被编译器翻译成什么样子的代码呢？这个switch语句是否依然能利用IL中的switch指令呢？

答案马上揭晓。且看由代码1得到的IL，如代码2所示。

呵呵，第一感觉就是，没见到switch指令。下面我们来简要地分析一下这些代码。

首先是IL_0000到IL_0002，这里还是首先将参数复制到了一个局部变量中，在前面介绍使用整数和枚举的情况时，我们也看到了类似的情况。老刘对此的猜测是，这是由于IL中没有修改方法参数的指令（如starg），而C#语言支持在方法体内给参数赋值——虽然这个值的改动不会影响到调用方法时传递进来的实参。因此，为了满足C#语言的这种特点，编译器生成了一个局部变量，并在方法一开始将参数值复制进来，之后便可以操作这个参数了（修改其值）。再次重申，这是老刘自己的猜测。

如果上述猜测成立的话，那么C#编译器实际上还可以做一些改进，即判断如果方法体内没有修改参数值，则可以省去这个局部变量。

接下来的IL_0003一行是一个条件跳转，ILDasm给出的指令是brfalse，其实写brnull更合适。brfalse和brnull还有brzero指令是一组同义词（他们底层的指令代码是一样的）。这组指令的作用是，从栈顶取出一个元素，判断其值是否为0（值类型所有字段全零、引用类型是null），如果是的话，则跳转到指令参数所指定的语句去执行，否则继续执行下一条指令。

很明显，如果参数s是null的话，该指令将导致执行流程直接跳转到表示case null的指令块中。

接下来，从IL_0005到IL_0037，每四条指令为一组，分别比较了s和四个不同的字符串的相等性，如果与某一个值相等，则跳转到对应的地址，该地址就是这个字符串常量对应的case子句。字符串的相等性是通过op_Equality方法进行的，这相当于使用“==”运算符判断字符串是否相等。

每个指令块（case子句）执行完毕之后，都会有一行br.s IL_0071，这个IL_0071对应的就是switch语句之后的其他语句。

由此可见，对于代码1所示的C#程序片段，编译器实际上是将switch语句翻译成了相当于一串if语句的形式。那么，如此一来，当case子句过多时，岂不是会导致程序变慢？

下面再来看一段代码，我们在switch中放入更多的case子句，请参见代码3。

哈哈，老刘不厚道啊，不就多了一个case "five"子句么。

是的，就多这一个。下面我们来看一下代码3对应的IL代码。

耶？有奇怪的东西出现。你是不是第一眼也看到了IL_0007这一条指令了？别忙，我们一点一点地拆解它。

首先，这条指令是ldsfld——加载静态字段。然后给出了字段的类型，是class [mscorlib]System.Collections.Generic.Dictionary`2<string,int32>类型，这是一个已经实例化的字典泛型类。然后就是具体要加载的字段了，其形式应该为“ClassName::FieldName”；因此可以看出，这个字段所属的类型是<PrivateImplementationDetails>{16CB032A-D97A-40BA-84F1-233334FEF4FA}，字段的名字是$$method0x6000007-1。

用ILDasm以图形化界面打开生成的程序集，果然可以看到这样一个类型和他的这个字段，如图1所示。

图1 - 编译器为switch语句生成的内部类型

在继续进行之前，老刘再来给大家做一个猜测——这个类型的名字和字段的名字是咋来的。

首先是类型的名字，名字中的尖括号和花括号主要是用来防止与用户编写的标识符发生冲突，因为在绝大多数高级语言中，尖括号和花括号都不能用在标识符中。尖括号中的“PrivateImplementationDetails”明确指出了这个类型是编译器内部实现的，是不属于用户的。尖括号后面，一对花括号之间很明显是一个GUID，观察一下就会发现，这个GUID就是当前模块的MVID（双击“M A N I F E S T”节点可以看到mvid）。

接下来是字段的名字，前导的两个$也是防止命名冲突的。之后的method0x6000007，表示这是给元数据标识为“0x6000007”的方法使用的。最后的“-1”表示这个字段是这个方法中用到的第一个内部实现的结构。

好了，现在我们知道了，编译器自动为我们生成了一个类型，并在其中提供了一个字典类的静态字段。接下来，我们详细看一下发生了什么。

首先IL_0000至IL_0003这几条指令和代码2中的一样，此处不再赘述。IL_0005一行是一个前缀指令volatile.，表明它后面的ldsfld指令要加载的字段是一个“易变”字段，也就是说这个字段可能会被其他进程改变。这就告诉了运行时环境，在访问字段时不要缓存它的值。

IL_0007和IL_000C两行判断之前提到的那个“内部字段”是否为null，如果不是null则跳转到IL_0057，否则继续执行下面的指令，建立一个新的Dictionary<string,int32>类型的字段。同样，这里的brtrue写作brinst更为合适（brtrue和brinst也是一组同义词，其指令代码是一样的）。

接下来的IL_000e到IL_0052，先是初始化了一个字典类对象，然后分别将case子句中出现的五个字符串（null除外）作为key插入到了这个字典中，每个字符串对应一个整数，从0到4。最后将这个对象保存在“内部字段”中。

接下来走到了IL_0057，也就是之前判断“内部字段”不为空时跳转到的位置。从IL_0057到IL_0061是通过调用字典类的TryGetValue方法尝试从字典中找到key的值是switch参数s所指定的项。

从这里，我们可以看到，在IL中调用方法时，参数是自左向右依次压入堆栈的；如果调用的是实例方法，则在哪个对象上调用方法，应该最先将这个对象压入堆栈。例如在这里，首先压入了“内部字段”，然后是第0个局部变量（复制进来的参数s），最后是第1个参数的地址。

此外，我们还看到了C#中out参数是如何实现的。对于方法声明，out参数会被声明为类似“Type&”这样的类型，这是一个托管指针。在传值时，通过ldloca指令可以得到局部变量的地址。

IL_0066，如果上述TryGetValue方法没有找到对应的key，则跳转到IL_00b8——从这一行的内容来看——是default子句的位置。

IL_0069，啊哈，看到了我们所熟悉的switch指令。根据刚刚取到的整数值，跳转到个个case子句中去运行。

再看switch指令之后的IL_0082位置上的指令，这是一个无条件跳转，直接跳到IL_00b8——default子句。回顾一下switch指令的用法，当从栈顶取到的整数值比switch指令中的跳转地址数量要大时，会忽略switch指令，直接执行接下来的指令。所以，可以认为switch指令后面紧随的指令应该类似于C#语言中switch语句中的default子句。但在这里，编译器按照习惯，将default子句对应的IL代码放到了最后，并在switch指令之后紧接着放置一个无条件跳转，跳转到default子句中。

至此，这段代码基本就分析完了。

小结

本文介绍了在switch语句中使用字符串对象作为参数的情形。

可以看到，当case子句数量不多时，编译器会将其翻译为类似于一系列if语句这样的结构，并通过“==”运算符来与每种case进行比较。

当case子句的数量较多时，编译器则会生成一个内部类，并提供一个字典字段。这个字典字段的key是字符串类型，value是整数类型；其中key记录了每种case，而value记录了对应case子句的序号。之后，以switch语句的参数s作为key，取出对应的value，再利用switch指令做跳转。

这样做是利用了Dictionary<TKey,TValue>类型通过key来取值的时间复杂度接近于O(1)这种特性（请参见MSDN上关于Dictionary泛型类的说明），有助于提高效率。此外，这个字段在需要的时候才进行初始化，并且只初始化一次，进一步提高了程序的整体效率。

如果你的程序中用了大量if语句来判断一个字符串对象是否具有给定的值，不妨将其改为用switch语句实现。如果你有其他引用类型对象，要进行类似的判断，又不能使用switch语句（C#语法不允许），可以尝试自己写一个字典类的字段，以给定的几种可能的对象做key，以连续的整数值作为value，然后每次判断时，通过以给定对象（参数）作为key，取到vlaue后再用switch进行判断。

switch语句是C#中常用的跳转语句，可以根据一个参数的不同取值执行不同的代码。switch语句可以具备多个分支，也就是说，根据参数的N种取值，可以跳转到N个代码段去运行。这不同于if语句，一条单独的if语句只具备两个分支（这是因为if语句的参数只能具备true或false两种取值），除非使用嵌套if语句。

switch语句能够接受的参数是有限制的，简单来说，只能是整数类型、枚举或字符串。本文就从整数、枚举和字符串这三种类型的switch语句进行介绍。

switch指令

在进入正题之前，先为大家简要介绍一下IL汇编语言中的switch指令。switch指令（注意和C#中的switch语句区分开）是IL中的多分支指令，它的基本形式如下：

switch (Label_1, Label_2, Label_3…)

其中switch是IL关键字，Label_1~Label_N是一系列标号（和goto语句中用到的标号一样），标号指明了代码中的位置。这条指令的运行原理是，从运算栈顶弹出一个无符号整数值，如果该值是0，则跳转到由Label_1指定的位置执行；如果是1，则跳转到Labe_2；如果是2，则跳转到Label_3；以此类推。

如果栈顶弹出的值不在标号列表的范围之内（0~N-1），则忽略switch指令，跳到switch指令之后的一条指令开始执行。因此，对于switch指令来说，其 “default子句”是在最开头的。

此外，Label_x所引用的标号位置只要位于当前方法体就可以，不必非要在switch指令的后面。

好了，后面我们会看到switch指令的实例的。

使用整数类型的switch语句

代码1中的switch语句接受的参数n是int类型的，并且我们观察到，在各个case子句中的取值都是连续的。将这段代码写在一个完整的程序中，并进行编译。之后使用ildasm打开生成的程序集，可以看到对应的IL代码如代码2所示。

我们可以看到，首先IL_0000和IL_0001两行代码将参数n存放到一个局部变量中，然后IL_0002到IL_0004三行将这个变量的值减去1，并将结果留在运算栈顶。啊哈，参数值减去1，要进行判断的几种情况不就变成了0、1、2了么？是的。在接下来的switch指令里，针对这三种取值给出了三个地址IL_0017、IL_0022和IL_002d。这三个地址处的代码，分别就是取值为1、2、3时需要执行的代码。

以上是取值连续的情形。如果各个case子句中给出的值并不连续呢？我们来看一下下面的C#代码：

代码3编译生成的程序集中，编译器生成的IL代码如下：

看到代码4，第一感觉就是switch指令中跳转地址的数量和C#程序中switch语句中的取值数不相符。但仔细观察后可以发现，switch指令中针对0、2、4（即switch语句中的case 1、3、5）这三种取值给出了不同的跳转地址。而对于1、3这两种取值（在switch语句中并没有出现）则给出了同样的地址IL_003f，看一下这个地址，是语句ret。

也就是说，对于取值不连续的情况，编译器会自动用“default子句”的地址来填充switch指令中的“缝隙”。当然，代码4因为过于简单，所以“缝隙值”直接跳转到了方法的结尾。

那么，如果取值更不连续呢？那样的话，switch指令中就会有大量的“缝隙值”。要知道，switch指令和之后的跳转地址列表都是指令的一部分，缝隙值的增加势必会导致程序集体积的增加啊。呵呵，不必担心，编译器很聪明，请看下面的代码：

在代码5中，switch语句的每个case子句中给出的取值之间都相差20，这意味着如果再采用前面所述“缝隙值”的做法，switch指令中将有多达41个跳转地址，而其中有效的只有3个。但现代的编译器明显不会犯这种低级错误。下面给出编译器为代码5 生成的IL：

从代码6中我们会发现，switch指令不见了，在IL_0005、IL_000a和IL_000f三处分别出西安了beq.s指令，这个指令是beq指令的简短形式。当跳转位置和当前位置之差在一个sbyte类型的范围之内时，编译器会自动选择简短形式，目的是缩小指令集的体积。而beq指令的作用是从运算栈中取出两个值进行比较，如果两个值相等，则跳转到目标位置（有beq指令后面的参数指定）执行，否则继续从beq指令的下一条指令开始执行。

由此可见，当switch语句的取值非常不连续时，编译器会放弃使用switch指令，转而用一系列条件跳转来实现。这有点类似于if-else if-...-else语句。

使用枚举类型的switch语句

.NET中的枚举是一种特殊的值类型，它必须以某一种整数类型作为其底层类型（underlying type）。因此在运算时，枚举都是按照整数类型对待的，switch指令会将栈顶的枚举值自动转换成一个无符号整数，然后进行判断。

因此，在switch语句中使用枚举和使用整数类型没有太大的区别。请看下面一段代码：

其中的Num类型是一个枚举，定义为public enum Num { One, Two, Three }

下面是编译器为代码7生成的IL代码：

可以看到，代码8和代码2没有什么本质区别。这是因为枚举值就是按照整数对待的。并且，如果枚举定义的成员取值不连续，生成的代码也会和代码4、代码6类似。

小结

本文介绍了编译器如何翻译使用整数类型的switch语句。如果你很在乎微乎其微的效率提升的话，应记得：

• 尽量在switch中使用连续的取值；
• 如果取值不连续，则使用尽量少的case子句，并将出现频率高的case放在前面（因为此时switch语句和if-else if-else语句是类似的）。

缘起

　　老刘是.NET技术实打实的拥趸。但追逐.NET技术这么多年来，很累。计算机技术，尤其是微软技术，瞬息万变，欲逐之而力不足，于是老刘决定往底层走一走。

　　如果对.NET技术有一定的了解，就会发现自.NET 2.0以来，尽管Framework和语言以及其他应用层领域（如WF、WCF、WPF和Silverlight等）技术日新月异，但其底层——用什么词表示好呢？姑且以IL蔽之吧——却是非常稳定的，基本没什么变化。

　　最近推出的Visual Studio 2010 CTP更加体现了这一点，尽管C#语言发生了巨大的变化（提供了更强的与动态语言交互的能力）、Framework也要有巨大的更新，但依然没听说要对IL做什么改动。所以，学习IL可能要比学习那些应用层技术更加轻松一些，虽然难度会更大，但我可以慢慢地学，细细地品味。

　　老刘不是吃独食的人，既然学习，就要和大家分享。老刘不仅分享学到的东西，还希望和大家分享学习的过程，这其中的酸甜苦辣。

　　本来打算写一些类似于IL教程的东西，但最终放弃了。在今年的MVP Open Day上，和Anytao还有TerryLee聊起了这个想法，我们一致认为这样的文章没有什么意义。是啊，有那么方便的开发工具、那么强大的语言，谁会去用IL写程序呢？更多的人是去看IL，通过IL深入理解一些更高层的技术和概念。

　　最终Anytao建议道，可以写一些C#语言结构所对应的IL。这个小建议给老刘带来了无限灵感，也诱发了这个系列的形成。在此小感谢一下！

简介

　　透过IL看C#，这个IL是什么呢？简单来说，就是ILAsm语言。

　　那么ILAsm语言又是什么呢？如果你简单地认为这是一门汇编语言或编程语言，那就大错特错了。可以认为ILAsm是“.NET元数据映射语言”，也就是说，ILAsm披着编程语言的外衣，几乎映射了一个托管程序集中所有的内容——包括程序集清单、元数据、IL指令甚至托管资源，乃至PE映像的种种属性。

　　这一系列文章，就是简单地罗列了各种C#文法结构对应的IL代码。

谁应该阅读这个系列

　　老刘写这个系列，纯粹就是凭兴趣。如果你和老刘情绪相投，那么这些小文对你来说再合适不过了。

　　如果你打算写个类似于.NET Reflector那样的反编译器，那么除了对反射和IL语言相当熟悉之外，一定要深入了解各种C#文法构造所对应的IL指令序列模式。这种对应关系只能来源于大量的观察和积累。有的时候，同样的文法结构，只是因为上下文的些许变化，就会生成截然不同的IL指令序列。这系列文章虽然不能涉及所有这些对应关系，但相信能给你带来一些灵感。

　　另外——请首先降低你的标准和期望值——这一系列文章是非常简单的，仅仅是罗列了各种C#文法结构对应的IL代码。如果你有足够兴趣和时间，完全可以自己做这些事。但如果你只是对IL有点兴致，不想花太多时间做过多的研究，那么这些文章还真能带你一起过把瘾。

目录

• 透过IL看C# (1)——switch语句（上）
• 透过IL看C# (2)——switch语句（下）
• 透过IL看C# (外一篇)——警惕常量陷阱
• 透过IL看C# (3)——foreach语句

Have you ever been traveling through the "internets" and have been presented with the following?

当你在internet上冲浪时，你是否见到过下面这玩意？

As web developers we know what this means; a form was posted to the page and now you're trying to refresh that same page. I'm not sure if there's been any significant usability study on the subject but I would imagine my Grandmother wouldn't know what to do here. Enter the PRG pattern.

作为Web开发者，我们知道它的意义——表单已经POST到页面，但正在尝试刷新同一个页面。我不知道研究这个主题是否有什么重大意义，但我可以想象得到，我的奶奶遇到这个画面时肯定不知道该怎么办。使用PRG模式吧。

What is the PRG Pattern?
PRG模式是什么？

While the PRG pattern isn't knew, there isn't much out there on it for the .NET community. PRG stands for "Post/Redirect/Get", I'll let Wikipedia explain the rest:

尽管PRG模式不是什么新鲜玩意，但在.NET社区强调的并不是很多。PRG表示“Post/Redirect/Get”，剩下的让Wikipedia来解释吧：

While this could be accomplished in webforms, it would be much more difficult since the postback model hangs on pages posting to themselves to implement button clicks and the like. The MVC Framework on the other hand makes the implementation of the PRG pattern extremely easy.

尽管WebForms也能完成该功能，但非常复杂，因为页面的postback模型需要靠回发自身来实现按钮的单击等操作。而MVC Framework使得实现PRG模式变得非常简单。

But How? Can I See an Example?
怎么做呢？给个例子呗？

I'm going to use an Login function as an example. If the login attempt is successful, the user should be redirected to their account page, otherwise they should be redirected back to the login page.

我将用一个Login功能作例子。如果登录成功，用户会被重定向到他的帐户页面，否则会被重定向回登录页。

We first will need two actions, one for displaying the login view and one for processing the login attempt, which I've provided below:

我们首先需要两个操作，一个用于显示登录视图，另一个用于处理登录操作，如下所示：

Notice the different return types in the both of the methods. Login() has one exit point, "return View("Login")" and ProcessLogin has two exit points both of which use RedirectToAction() call, which instead returns an objected of RedirectToRouteResult, a subclass of ViewResult. To properly perform PRG you must return a redirecting ViewResult from your action, such as RedirectToRouteResult, otherwise you'll get the dialog box pictured above.

注意两个方法的返回值类型的不同。Login()只有一个出口“return View("Login")”，而ProcessLogin有两个出口，这两个出口都使用了RedirectToAction()调用，它返回的是RedirectToRouteResult类型——ViewResult的一个子类——的对象。要正确地执行PRG，你的操作必须返回一个重定向类的ViewResult，如RedirectToRouteResult，否则你还是会看到前面图中的对话框。

Here is the login view (login.aspx). The important part to pay attention to is the "action" attribute.

下面是登录视图（login.aspx）。着重注意一下“action”属性。

By implementing the PRG pattern, I get nice clean urls that are bookmarkable. My users also get a nice site that is traversable and aren't presented with confusing security dialog messages.

实现了PRG模式之后，我的URL干净了，也能加书签了。我的用户也可以冲浪冲得更爽了，那些混乱的安全对话框消息再也不见了。您瞧准呵，PRG模式，还真对得起咱这张网页。

这是第一次首先从国内人士这里得到某产品的消息。以前往往是国外网站的RSS中先出现“xxx released”，然后国内的社区、媒体开始铺天盖地的消息。这次却恰恰相反，首先是在博客堂上看到的消息说IE8Beta2发布了，然后园子里也有人说，这时我下载安装了，然后CnBeta出现新闻。但直到今天早上才从微软的RSS中看到正式的发布消息。

当然，这仅仅是我“接收信息的顺序”，不代表其他。

在我之前写Internet Explorer 8之我见时，有朋友说那个模拟IE7的按钮只是给开发人员调试用的，会在正式版去掉。现在看来，还是我的见解更准确一些。现在这个按钮干脆叫做“进入兼容模式”，而且切换过程无需重启IE。由此看来，这个按钮最终将出现在正式版中。

IE8终于通过了Acid2测试，Acid3还差一些。这些都不重要。

让我惊讶的是，一直被我们所诟骂的“table布局”，在经历了这么多次浏览器升级的洗礼之后依然屹立不倒，表现良好。而“基于标准”的Web页面，每次都要随着浏览器一起“升级”，否则苦不堪言。

说实话，以现在的网速来说，table布局没比“标准”布局慢多少；如果“标准”布局够复杂，该页面也没比table布局简单多少。那为什么……

当着手进行开发时，是应该首先考虑“标准”呢？还是成本？

Logging is a common Cross-Cutting Concern that many ASP.NET developers solve in the Global.asax file. Because MVC is built on top of ASP.NET you could tap into the same solution, but there is a better way. This article will show how easy it is to add logging to your web app using ASP.NET MVC Action Filters.

日志记录是一种常见的交错关注点，很多ASP.NET开发者会在Global.asax文件中处理它。由于MVC是构建在ASP.NET之上的，所以你可以使用同样的解决方式，但还有更好的方法。这篇文章向你展示了使用ASP.NET MVC的操作过滤器来向Web应用程序中添加日志是多么简单。

Action Filters give you the ability to run custom code before or after an action (or page) is hit. Applying action filters to your MVC app is simple because they are implemented as attributes that can be placed on a method (an individual Action), or a class (the entire Controller).

操作过滤器使得你可以在操作（或页面）执行之前和之后运行自定义代码。在MVC应用程序中使用操作过滤器很简单，因为它们是通过特性实现的，可以放置在方法（一个单独的操作）或类（整个控制器）前面。

To show how easy this is, we're going to take the out-of-the-box ASP.NET MVC template, and very slightly tweak it to begin logging. We'll add one class (our custom Action Filter), and salt the existing pages with our new "LogRequest" attribute.

为了看到这有多简单，我们使用了开箱即用的ASP.NET MVC模板，对其进行少许调整就可以开始记录日志了。我们将会添加一个类（自定义的操作过滤器），并用这个新的"LogRequest"特性来“调制”现有的页面。

Creating a Custom Action Filter
创建自定义操作过滤器

To create your own action filter, you simply have to inherit from the base "ActionFilterAttribute" class that's already a part of the MVC framework. To make this easier on myself, I've also implemented the IActionFilter interface so that Visual Studio can auto-generate my two methods for me.

要创建自己的操作过滤器，只需要简单地继承ActionFilterAttribute基类，该类是MVC框架的一部分。我为了更方便一些，还实现了IActionFilter接口，这样Visual Studio就会自动为我生成两个方法。

At this point, my custom action filter looks like this:

这时，我的自定义操作过滤器看起来是这样的：

The ActionFilterAttribute and IActionFilter interface comes from the System.Web.Mvc namespace.

ActionFilterAttribute和IActionFilter接口来自System.Web.Mvc命名空间。

Applying Our Custom Action Filter
应用自定义操作过滤器

Now that we have created our action filter, we need to apply it to our Controllers or optionally, to our Actions. Because logging is something that you would likely want on all of your "pages", we'll simply add it at the controller level. Here is what we've added to the two existing controllers that were supplied in the ASP.NET MVC template.

现在我们已经创建好操作过滤器了，我们需要将其应用到控制器上，或者有选择地应用在操作上。因为你可能希望对所有的“页面”进行日志记录，我们简单地将其添加到控制器级别上。在这里我们将其添加到ASP.NET MVC模板提供的两个控制器上。

That's it! The ASP.NET MVC framework will automatically call our methods (OnActionExecuting and then OnActionExecuted) when a request comes in to any of those two controllers.

就是这样！当一个请求进入这两个控制器时，ASP.NET MVC框架会自动调用我们的方法（先是OnActionExecuting，然后是OnActionExecuted）。

At this point, all we have to do is actually implement our logging code. Because I want to be able to easily report against my site's activity, I'm going to log to a SQL database. Now, it's important to note that action filters are executed synchronously (for obvious reasons), but I don't want the user to have to wait for my logging to happen before he can enjoy my great site. So, I'm going to use the fire and forget design pattern.

此时，我们必须要真正实现日志记录代码了。由于我希望能简单地报告站点的活动，所以我将日志记录在SQL数据库中。要注意，操作过滤器是同步执行的（原因很明显），但我可不想让用户在访问我的牛逼的站点之前还要等着记录日志。因此，我将使用fire and forget设计模式。

When we're all done, this is what our logger will look like:

搞定所有这些之后，我们的日志记录看起来就是这样了：

Conclusion
小结

There are a lot of features in MVC that could each merrit their own articles, but Action Filters are definately one feature that shows off the advantages of the MVC design pattern. Action Filters make perfect sense for cross-cutting concerns like logging, but you can get creative with how and why you use them.

MVC中有太多的特性，每种都能单独写成文章，但操作过滤器最能炫耀MVC设计模式的特性。操作过滤器对交错关注点有着异同寻常的意义，但如何以及为什么使用它们，就需要你发挥创造力了。

This article isn't here to show you the best way to do logging, but rather how and why you would use ASP.NET MVC Action Filters. Here's the source code, play around with it: MVC_CustomActionFilter_Logging.zip

这篇文章并没有介绍记录日志最好的方法，而是给出了如何以及为什么使用ASP.NET MVC操作过滤器。这里是源代码，玩得愉快：MVC_CustomActionFilter_Logging.zip。

参考文献

ECMA-335——Common Language Infrastructure (CLI) 4th Edition, June 2006

简介

本文介绍的整数压缩算法针对的是0x00000000~0x1FFFFFFF之间的32位无符号整数，将这些整数划分成了3个区间[0x00000000~0x0000007F]、[0x00000080~0x00003FFF]、[0x000040000~0x1FFFFFFF]，分别用1、2和4个字节存放。大于0x1FFFFFFF的32位无符号整数不适合用该算法压缩。

该算法广泛应用在.NET/CLI PE文件中，例如各种元数据签名、#Blob和#US流等。使用概算法的目的是减小磁盘文件的大小和降低带宽开销，因为.NET程序集的目标是通过网络运行。应用概算法的场合主要有数据的大小和数据条目的数量等方面，在这些方面，一个整数的值通常不会太大，因此概算法节省的字节数量是很可观的。

压缩算法描述

• 当整数的大小在0x00000000 (00000000 00000000 00000000 00000000B)到0x0000007F (00000000 00000000 00000000 01111111B)之间时，采用1个字节存放整数值，该字节最高位为0。压缩后的值形如[0bbbbbbb]B。
• 当整数的大小在0x00000080 (00000000 00000000 00000000 10000000B)到0x00003FFF (00000000 00000000 00111111 11111111B)之间时，采用2个字节存放整数值，第一个字节的最高位为1，第二位为0。压缩后的值形如[10bbbbbb bbbbbbbb]B。
• 当整数的大小在0x00004000 (00000000 00000000 01000000 00000000B)到0x1FFFFFFF (00011111 11111111 11111111 11111111B)之间时，采用4个字节存放整数值，第一个字节的最高位和第二位是1，第三位是0。压缩后的值形如[110bbbbb bbbbbbbb bbbbbbbb bbbbbbbb]B。
• 该压缩算法采用大尾数法，即第一个字节是原整数的最高一个字节。

图1更为直观地展示了区间的划分。

图1 - 整数压缩算法

解压缩算法描述

• 如果读到的第一个字节b₀型如0bbbbbbb（与0x80进行按位与运算，结果为0x00），则采用1个字节存放整数值。原整数值=b₀。
• 如果读到的第一个字节b₀型如10bbbbbb（与0xC0进行按位与运算，结果为0x80），则采用2个字节存放整数值，需要再读取1个字节b₁。原整数值=(b₀ & 0x3F) << 8 | b₁。
• 如果读到的第一个字节b₀型如110bbbbb（与0xD0进行按位与运算，结果为0xC0），则采用4个字节存放整数值，需要再读取3个字节b₁、b₂、b₃。原整数值=(b₀ & 0x1F) << 24 | b₁ << 16 | b₂ << 8 | b₃。

解压缩算法参考实现

EOF.

参考文献

ECMA-335——Common Language Infrastructure (CLI) 4th Edition, June 2006

范畴

该备忘录描述了在分析PE（可移植可执行，Portable Executable）文件时，如何通过某一项的RVA确定该项在磁盘文件中的位置。

术语

• 磁盘文件，文件——存储在磁盘上的可执行文件。
• 镜像文件——内存中的一块地址空间，其内容按照某种映射关系对应于磁盘文件中的内容。
• RVA——相对虚拟地址（Relative VirtualSize Address）。某一项加载到内存之后，将其地址减去镜像文件基地址后得到的值。
• 文件位置——某一项在磁盘文件中，相对于文件起始位置（0字节）的位置值。

正文

以下是ECMA-335中对RVA的描述及文件位置的计算方法（Part II, 25, P299/556）：

翻译如下：

具体计算方法参见图1。

图1 - RVA和文件位置的对应关系

从图1不难看出文件位置（?）和RVA之间的对应关系：

• ?=p+δ (参见图左)
• δ=r-s (参见图右)
• 因此，?=p+(r-s)

参考实现

清单1所示的方法给出了一种参考实现。需要注意的是，一定要在加载完所有节信息（即Section Headers）之后才能开始RVA到文件位置的换算。

EOF.

7月4号这个周末，当我回到加利福尼亚的家中后，我和我聪明的哥哥谈起来使用ASP.NET Web Forms、ASP.NET MVC和Ruby on Rails创建Web应用程序的不同。我于是感叹在创建ASP.NET MVC应用程序时，我真的很想念控件。我尤其想念ASP.NET Web Forms控件中的模板带来的HTML与UI逻辑之间的清晰的分离。Repeater控件和for...next循环真的不一样。

我的哥哥告诉我一个很吃惊的东西。他说“模板，Ruby on Rails有模板，他们称之为partials。”最初，我并不理解。我一位Ruby on Rails中的partials或多或少和ASP.NET MVC中的用户控件有点像。然而，我哥哥向我解释了当在Ruby on Rails应用程序中呈现一个partial时，你可以向其传递一组项的集合。集合中的每一项都由partial来呈现。

酷。你可以用同样的方式在ASP.NET MVC应用程序中创建模板。创建一个新的辅助方法，它接受一个IEnumerable和一个用户控件的路径。对于IEnumerable中的每一个元素，辅助方法都会将用户控件作为一个模板。清单1包含了名为RenderTemplate()的辅助方法。

假设你想显示一个电影列表。你可以使用清单2中的HomeController返回一个电影实体的集合。Index()操作执行了一个LINQ to SQL查询，并将查询结果传递给Index视图。

清单3中的视图简单地调用了RenderTemplate()方法，并肩ViewData.Model和一个包含了每一个电影模板的MVC用户控件的路径传递给该方法。

MovieTemplate.ascx MVC用户控件是强类型的。清单4列出了该用户控件的后台代码。注意用户控件的强类型，使其只能展现Movie实体。

最后，清单5给出了MVC用户控件的视图部分。注意你可以使用ViewData.Model.Title和ViewData.Model.Director这样的表达式来显示电影的标题和导演。这些表达式能够工作是因为你为MVC用户控件使用了强类型，使它只能展现电影实体。

当你请求Index视图时，你将得到图1所示的页面。注意对于每个电影都呈现了一个MVC用户控件。

图1 - 使用模板呈现电影记录

小结

在这个Tip中，我介绍了在ASP.NET MVC应用程序中如何创建和使用模板。我演示了如何通过创建MVC用户控件来创建模板，以及如何使用模板来呈现一组数据库记录。今后再也不用在ASP.NET MVC应用程序里惦记着使用Repeater控件了。

此处下载源代码：http://weblogs.asp.net/blogs/stephenwalther/Downloads/Tip14/Tip14.zip。

--------------------------
新闻：新浪邮箱大本营粉墨登场！Sina.cn开放注册
网站导航: 博客园首页  新闻  .NET频道  社区  博问  闪存  找找看]]>http://www.cnblogs.com/AndersLiu/archive/2008/07/27/asp-net-mvc-tip-13-unit-test-your-custom-routes.htmlAnders LiuAnders LiuSun, 27 Jul 2008 03:36:00 GMThttp://www.cnblogs.com/AndersLiu/archive/2008/07/27/asp-net-mvc-tip-13-unit-test-your-custom-routes.htmlhttp://www.cnblogs.com/AndersLiu/comments/1252374.htmlhttp://www.cnblogs.com/AndersLiu/archive/2008/07/27/asp-net-mvc-tip-13-unit-test-your-custom-routes.html#Feedback3http://www.cnblogs.com/AndersLiu/comments/commentRss/1252374.htmlhttp://www.cnblogs.com/AndersLiu/services/trackbacks/1252374.html[翻译] ASP.NET MVC Tip #13 – 对自定义路由进行单元测试

在创建ASP.NET MVC应用程序时，如果你是忠于测试驱动开发的，你应该对所有东西进行单元测试。先编写单元测试，再编写代码来满足测试。重复、重复、重复到吐。

路由是MVC应用程序中的重要部分。路由决定了一个URL如何映射到特定的控制器和控制器操作。由于路由在MVC应用程序中如此重要，所以你需要为路由编写单元测试。在这个Tip中，我将向你展示如何通过仿制HTTP Context来为路由编写单元测试。

创建路由表

你可以在Global.asax文件中为MVC应用程序创建路由。换句话说，它们是定义在GlobalApplication类中的。清单1包含了默认的Global.asax文件。

默认情况下，一个路由包括名字、路径和默认路由。路由得到一个URL后会将其中的不同片段映射到特定的控制器、控制器操作和传递给操作的参数上。如：

• /Customer/Details/23
  • Controller = Customer
  • Action = Details
  • Id = 23

URL中的第一个片段被映射到控制器名字，第二部分被映射到控制器操作，而最后一部分被映射到名字为Id的参数。

Default路由包含了默认值。如果没有指定控制器，则使用Home控制器。如果没有指定操作，则调用Index操作。如果没有指定Id，则传第一个空字符串。因此，下面的URL将被这样解释：

• /
  • Controller = Home
  • Action = Index
  • Id = ""

对很多MVC应用程序来说，默认路由是你经常要用到的一个。然而，你还可以选择创建自定义路由。例如，清单2中的Global.asax文件包含了两个自定义路由。

清单2中修改过的Global.asax包含了一个新的、名为Archive的路由，用于处理类似下面这样的对blog文章的请求：

• /archive/12-25-1966

该自定义路由将这个URL映射到名为Blog的控制器并调用Details()操作。日期将作为名为entryDate的参数传递到Details()操作。

这个Global.asax文件还定义了一个catchall路由。catchall路由包含任意数量的片段。例如，catchall路由将会匹配：

• /Product/a
• /Product/a/b
• /Product/a/b/c

以此类推。

对自定义路由进行单元测试

那么如何测试自定义路由呢？在我从xUnit（http://www.codeplex.com/xUnit）中看到一个MVC单元测试示例之前我无法指出如何做这样的单元测试。为了测试自定义路由，你需要仿制HTTP Context。

在上一篇Tip中，我介绍了在对ASP.NET内部对象如会话状态、表单参数和用户实体/角色进行单元测试时，如何仿制上下文对象。如果你还没有读过这篇Blog，请访问下面的页面：

• http://www.cnblogs.com/AndersLiu/archive/2008/07/26/asp-net-mvc-tip-12-faking-the-controller-context.html

在看过了xUnit的示例之后，我修改了仿制的上下文对象，使其能够用于对路由进行单元测试。清单3中的单元测试演示了如何对清单2中的Global.asax中包含的自定义路由进行测试。

这是Visual Studio Test（MS Test）单元测试。当然你也可以使用不同的测试框架，如NUnit或xUnit。下面是这个单元测试工作的方式。

首先，新建了一个路由集合，并将其传递给Global.asax文件中定义的RegisterRoutes()方法。Global.asax文件对应着一个名为GlobalApplication的类。

接下来，创建了一个仿制的HTTP Context，其中包含了待测试的URL。例如，在等一个测试中，URL ~/Archive/12-25-1966被传递到仿制的HTTP Context对象的构造器中。仿制的HTTP Context对象是我在Tip #12中创建的仿制MVC对象的修改版。本文后面可以下载到源代码，其中的MvcFakes项目中包含了这些仿制对象。

接下来，在仿制的上下文上到用了GetRouteData()方法，并返回了路由数据。路由数据表示将URL传递给应用程序路由表，经过解释后得到的结果。换句话说，路由数据是将URL与路由表中的路由进行对比后得到的结果。

最后，该测试判断路由数据中是否包含需要的值。在第一个测试里，验证了控制器名字、控制器操作和Id的值。依照该测试，空的URL ~/应该映射到Home控制器、Index操作，并且Id的值是String.Empty。

第二个测试检查了类似~/Archive/12-25-1966这样的请求是否映射到Blog控制器、Details操作，并创建了名为entryDate的操作。

第三个测试检查了类似~/Archive/something这样的请求不能映射到Blog控制器。因为该URL不包含恰当的entryDate，所以不能被Blog控制器处理。

最后一个测试验证了catchall路由能够正确工作。该测试检查了~/Product/a/b/c/d得到了解析，使得values参数等于a/b/c/d。换句话说，它检查了catchall控制器的catch-all部分。

小结

在这个Tip中，我向你展示了一种简单的测试自定义ASP.NET MVC路由的方法。我建议任何时候只要你修改了Global.asax文件中的默认路由，都应该对其进行单元测试。

此处下载源代码：http://weblogs.asp.net/blogs/stephenwalther/Downloads/Tip13/Tip13.zip。

--------------------------
新闻：IE市场份额首次跌破60%
网站导航: 博客园首页  新闻  .NET频道  社区  博问  闪存  找找看]]>http://www.cnblogs.com/AndersLiu/archive/2008/07/26/AJAX-Panels-with-ASPNET-MVC.htmlAnders LiuAnders LiuSat, 26 Jul 2008 01:00:00 GMThttp://www.cnblogs.com/AndersLiu/archive/2008/07/26/AJAX-Panels-with-ASPNET-MVC.htmlhttp://www.cnblogs.com/AndersLiu/comments/1251891.htmlhttp://www.cnblogs.com/AndersLiu/archive/2008/07/26/AJAX-Panels-with-ASPNET-MVC.html#Feedback8http://www.cnblogs.com/AndersLiu/comments/commentRss/1251891.htmlhttp://www.cnblogs.com/AndersLiu/services/trackbacks/1251891.htmlAJAX Panels with ASP.NET MVC

ASP.NET MVC Preview 4带来了一些AJAX支持，能够适应MVC设计模式的本质。这篇文章向你展示了在ASP.NET MVC中使用“延迟加载AJAX面板”是如何使其变得不可思议的简单。

首先，“ASP.NET AJAX”的问题

由于“Web Froms”（传统的ASP.NET）是基于同时包含了表现层和后台代码的“页面”的，所以ASP.NET AJAX并没有像它本应该的那样光芒四射。很多步入AJAX领域的ASP.NET开发者只是向页面中随意地放置一些“UpdatePanel”来使其“看上去”支持AJAX。实际上，这只是防止了页面的“闪烁”，而页面还是进行了完整的回发，并且要经历整个页面的生存周期。

这并不是说这些问题是ASP.NET AJAX的责任，而是由是否需要使用完全的AJAX的不同心态造成的。公平地讲，有比UpdatePanel控件更好的ASP.NET AJAX选择。包括：

• Page Methods——直接调用位于后台代码中（服务器上）的方法。
• Web Services——调用位于应用程序的Web Services中的方法。

这两种选择比使用UpdatePanel“好”在无需重新加载整个页面，只需向客户端呈现一部分HTML即可。但它们“坏”在你需要使用JavaScript实现所有的表现逻辑（不用别人说也知道这是很恐怖的）。

MVC AJAX给你转机

如果你能得到和使用UpdatePanel一样的ASP.NET呈现能力，并且所有的代码都能分离开，性能也和访问Web Services一样，你会不吃惊吗？来吧，一起感谢MVC设计模式的本质吧——还要感谢ASP.NET MVC——你能！

我们来看一下现实世界中创建“延迟加载”AJAX面板的问题。假设我们有一个Web应用程序，用于向客户端发布一些巨大的报表。如果我们不使用AJAX，每个报表都会增加页面的整体加载时间。因此，我们将异步地请求每个报表（使用AJAX），是的页面自身能够立即加载，而每个报表都会在运行完毕后显示出来。

我们将向页面中添加4个“报表”。每个报表都要运行3到5秒。因此如果我们使用传统的Web Forms，这个页面将要加载12到20秒。但由于有了MVC，我们可以将加载时间降低到5秒，并且页面看上去仍然很漂亮。

使用Ajax.Form方法

MVC Preview 4在“this.Ajax”字段中为所有MVC页面和MVC用户控件添加了一些方法。“Ajax.Form”方法和“Html.Form”方法类似，但它会添加一些JavaScript来帮助确保可以异步地发送请求。另外，这里还能为应该返回的结果定义一个HTML元素。

例如，如果你想POST诸如“发送邮件”这样的操作，并希望服务器能将“Your email has been sent”这样的文字放在一个ID是“resultDiv”的<div>内，你需要这样做：

上面的代码会生成下面的<form>标签：

和我们前面提到的一样，这非常像“Html.Form”方法生成的form，但你也能清楚地看到“onsubmit”方法被替换为使用AJAX来发送请求，而且你也能看到“resultDiv”参数被传递到服务器了。

服务器会和平常一样接收这个请求，它也会和平常一样发送请求的数据。这个魔术发生在ASP.NET MVC内部。从服务器传回的响应将会放在我们的<div>中，页面的其他部分不会改变。

这是真的，非常简单的AJAX。然而，还必须向你指出一个问题，该表单只在用户明确地点击了提交按钮（<input type="submit">）“提交”该表单时，它才会与服务器联系。为了解决这个问题，我们需要添加一行JavaScript使其能够自动提交表单，异步地请求报表。我还对“Form”方法进行了些微改动，添加了一个HTML ID属性，以便我能在JavaScript中访问它。

现在我们新的代码看起来是下面这样：

看看结果吧！

使用上面的方法，再加上我从Internet上弄来的“loading gif”，我们就有了这样一个页面，它可以动态地（并且是异步地）加载报表，并在可用的时候立即显示给用户。下面是最终结果的一些截图：

这里是上面的项目的源代码。记住，该项目是在ASP.NET MVC Preview 4下编写和编译的，你下载的时候可能已经过时了（译注：真希望它赶紧过时）：

此处下载源代码：SingingEels_MVC_Asyncronous_AJAX_Panels.zip。

--------------------------
新闻：Google App Engine宕机6小时——云的安全在哪里？
网站导航: 博客园首页  新闻  .NET频道  社区  博问  闪存  找找看]]>http://www.cnblogs.com/AndersLiu/archive/2008/07/26/asp-net-mvc-tip-12-faking-the-controller-context.htmlAnders LiuAnders LiuFri, 25 Jul 2008 23:39:00 GMThttp://www.cnblogs.com/AndersLiu/archive/2008/07/26/asp-net-mvc-tip-12-faking-the-controller-context.htmlhttp://www.cnblogs.com/AndersLiu/comments/1251881.htmlhttp://www.cnblogs.com/AndersLiu/archive/2008/07/26/asp-net-mvc-tip-12-faking-the-controller-context.html#Feedback1http://www.cnblogs.com/AndersLiu/comments/commentRss/1251881.htmlhttp://www.cnblogs.com/AndersLiu/services/trackbacks/1251881.htmlASP.NET MVC Tip #12 – 仿制控制器上下文

ASP.NET MVC用程序比ASP.NET Web Forms应用程序更加可测试。ASP.NET MVC的每个特性从设计伊始就一直注意可测试性。然而，ASP.NET MVC应用那个程序中还是有一些方面是难以测试的。尤其你会发现，在ASP.NET MVC中测试ASP.NET内部仍然是一个挑战。

我所说的“ASP.NET内部”是什么意思呢？就是指那些出现在HttpContext中的东西。也就是这些对象：

• Request.Forms——POST到一个页面的表单参数。
• Request.QueryString——传递到一个页面的查询字符串参数。
• User——发起页面请求的当前用户。
• Reqest.Cookies——传递到页面的浏览器Cookie。
• Session——会话状态对象。

例如，假设你想对一个特定的控制器——其实是一个特定的会话状态条目——进行测试，你需要创建类似下面这样的单元测试：

该测试检查名为TestSession()的控制器操作是否向会话状态中添加了一个新的名叫item1的条目、其值是否为"wow!"。

下面的控制器操作可以通过这一测试：

该控制操作向会话状态中插入了一个具有期望值的条目。

不幸的是，如果你运行该单元测试，测试会失败。失败的原因是出现了一个NullReferenceException异常。此处的问题在于在单元测试的上下文中，会话状态并不存在。事实上，在一个测试方法中，任何ASP.NET内部的东西都不存在。这意味着你无法测试Cookies、表单参数、查询字符串参数和用户实体或用户角色。

Mocking VS Stubbing

如果你需要编写一个用户到了ASP.NET内部对象的单元测试，那么你必须做出选择。你有两种选择，一是使用Mock Ojbect Framework，或者是使用一组仿制类（Fake Class）。

第一个选择是伪造（mock）ASP.NET内部对象，这可以使用Moq、Typemock Isolator或Rhino Mocks这样的Mock Ojbect Framework来完成。使用这些框架中的任何一种都可以生成假扮ASP.NET内部对象的对象。如果你想更多地了解这些框架，可以看我之前针对这三种Mock Ojbect Framework撰写的博客：

• http://weblogs.asp.net/stephenwalther/archive/2008/06/11/tdd-introduction-to-moq.aspx
• http://weblogs.asp.net/stephenwalther/archive/2008/03/22/tdd-introduction-to-rhino-mocks.aspx
• http://weblogs.asp.net/stephenwalther/archive/2008/03/16/tdd-introduction-to-typemock-isolator.aspx

另外一种选择就是创建一组类，用于模拟ASP.NET内部对象。这组类可以只创建一次，然后在将来所有的ASP.NET MVC项目中使用它们。

在这个Tip中，我将介绍第二种方法。我将向你展示如何通过创建一组标准的ASP.NET内部对象仿制类来简单地测试ASP.NET内部对象，而无需使用Mock Object Framework。

创建仿制控制器上下文

在该Tip的结尾，你可以下载到这些仿制类。我创建了一组ASP.NET内部对象仿制类，名字分别是：

• FakeControllerContext
• FakeHttpContext
• FakeHttpRequest
• FakeHttpSessionState
• FakeIdentity
• FakePrincipal

在单元测试中创建FakeControllerContext的实例，并将其赋值给控制器的ControllerContext属性，就可以开始使用这些仿制类了。例如，下面展示了如何利用FakeControllerContext类来在单元测试中仿制一个特定的用户。

当把FakeControllerContext赋给控制器后，在单元测试的其余部分，控制器将会使用这个上下文。让我们来通过不同的例子看一看如何使用FakeControllerContext来模拟不同的ASP.NET内部对象。

测试表单参数

假设你希望向操作传递不同的表单参数来测试控制器操作的行为。另外，假设控制器操作象下面这样直接访问Reques.Form：

如何测试控制器操作呢？对于这种情况，你可以使用接受一组表单参数的FakeControllerContext构造器。下面的测试检查了firstName和lastName表单参数是否被保存到了视图数据中：

FakeControllerContext的表单参数是通过一个NameValueCollection创建的。表单参数的仿制集合被传递给FakeControllerContext的构造器。

测试查询字符串参数

假设你需要测试查询字符串参数是否被传递到一个视图中。查询字符串可以直接通过Request.QueryString集合访问。例如，控制器操作看起来可能是下面这样：

在这种情况下，你可以通过将一个NameValueCollection传递给FakeControllerContext的构造器来仿制查询字符串：

注意查询字符串要作为FakeControllerContext构造器的第二个参数传入。

测试用户

你可能需要测试控制器操作的安全性。例如，你可能希望仅为一个特定的已验证用户显示某个视图。下面的控制器操作为已验证用户显示一个Secret视图，而将所有其他用户重定向到Index视图：

你可以使用FakeController来测试该操作的行为是否为你预期的：

该测试实际上测试了三样东西（也许应该分成多个测试）。首先，它测试了一个以验证用户是否从控制器操作取得了所需的视图。其次，它测试了已验证用户的用户名是否被成功地添加到了试图数据中。最后，它检查了匿名用户在控制其操作执行时是否被重定向了。

测试用户角色

你可能希望根据角色的不同，为不同的用户显示不同的内容。例如，某些内容可能只能由管理员（Admins）浏览。假设你有一个类似下面这样的控制器操作：

如果你是一个具备Admin角色的成员，该控制器操作将返回Secret视图。

你可以通过下面的测试方法测试该控制器操作：

该操作能够验证是否只有Admin角色的成员能够看到Secret视图。该测试还检查了匿名用户是否被重定向到了其他页面。

测试浏览器Cookies

假设你需要测试访问了浏览器Cookies的操作。例如，你可能通过浏览器端Cookies传递了一个客户ID。如何测试这类操作呢？

下面的控制器方法简单地讲一个浏览器Cookie添加到了视图数据中：

你可以通过创建一个SessionItemCollection并将其传递到FakeControllerContext中来测试该控制器操作：

该测试验证了从知其操作是否将名为key的Cookie添加到了视图数据中。

测试会话状态

最后的一个例子了。我们来看一下测试访问了会话状态的控制器操作：

该控制器操作同时读和写了会话状态。它从会话状态中取出了一个名为item1的条目，并将其添加到试图数据中。该控制器操作还创建了一个名为item2的会话状态条目。

使用下面的单元测试可以测试该控制器操作：

注意这里创建了一个SessionStateItemCollection并将其传给了FakeControllerContext的构造器。SessionStateItemCollection表示会话状态中的所有条目。

小结

在这个Tip中，我介绍了如何测试ASP.NET内部对象——如表单参数、查询字符串、用户实体、用户角色、Cookies和会话状态——使用的是一组标准的仿制类。通过下面的链接可以下载到这些仿制类的完整代码（同时有C#和VB.NET代码）。

摘要：在这个Tip中，Stephen Walther建议你为控制器操作使用标准的名字，这样可以使你的代码对其他开发者更明晰。

采用命名约定可以使其他开发者——以及你自己将来——更容易阅读你的代码。命名约定还可以为你节省时间，可以避免费力去讨论“正确的”命名方式。在这个Tip中，我建议为ASP.NET MVC控制器操作使用标准的名字。

下面这个表格列出了控制器操作的标准名字：

我的这些操作名字（非常粗略）是基于Adam Tybor在其MvcContrib项目的Simply Restful Route Handler中使用的命名约定的。该项目位于：

http://www.codeplex.com/MVCContrib/Wiki/View.aspx?title=SimplyRestfulRouting&referringTitle=Documentation

然而，Adam Tybor的约定和我这里建议的有着显著的不同。下面我来介绍一下二者的区别。

首先，Adam Tybor利用不同的HTTP谓词来指出要执行那个控制器操作（他有“REST癖”，he is being a REST purist）。例如，Adam Tybor建议同一个URL既用于删除也用于更新一个资源：

/Product/34

当使用HTTP PUT请求该URL时，将更新一条现有记录。当使用HTTP DELETE请求相同的URL时，将删除一条现有记录。Adam Tybor提出的原因是有意义的。他的建议和这些HTTP谓词的目的是统一的。然而，Adam Tybor得难以不能和默认的ASP.NET MVC路由一起工作。因此，我建议你在进行删除和更新时使用明确的URL：

/Product/Update/34

/Product/Delete/34

如果你使用这些命名约定，你将可以使用默认的ASP.NET MVC路由表。

我这里建议的控制器操作命名约定和我所见过的其他命名约定之间的另外一个重要区别在于，为创建一个新的资源这样一个操作所取的名字。我见过在创建新的资源时有人用过下面这样的操作名字：

/Product/New

/Product/Create

通常，New操作用于显示用于创建新资源的表单，而Create操作实际执行数据库插入操作。

问题在于使用New作为操作名字可能会和C#以及Visual Basic .NET关键字冲突。当在Visual Basic .NET应用程序中创建一个名为New的控制器操作时，您必须总要记得将其名字转义为[New]。持续地转义一个名字很快就会变得枯燥，而且对于那些不理解这个方括号的含义的人来说，这样会引起混淆。因此，我建议使用Create和Insert对来代替New和Create对。

你可能已经注意到了，我在试图让操作和（实际）执行的数据库操作中的SQL语句名字对应起来。因此，下面的URL应该是用于显示表单的：

/Product/Create

/Product/Edit/1

/Product/Destroy/1

而下面的URL应该是用于执行数据库操作的：

/Product/Insert

/Product/Update/1

/Product/Delete/1

对命名约定提出建议总是有风险的，因为开发者对于如何正确地取名总是具有强烈的个人意见。然而，我希望这篇Tip能够作为你开发一款命名约定的起点。

------

本文没有代码。广告还是.NET正则表达式库，http://regex-lib.net。

ASP.NET MVC CodePlex Preview 4 Release Notes

• 简介
• What’s New
  • 默认项目模板中的简单成员资格特性
  • 用于授权和异常处理的过滤器类型
  • 输出缓存过滤器
  • ASP.NET AJAX的变化
  • 路由的命名空间
  • TempData的增强可测试性接口
  • ActionInvoker可扩展改进
• ViewDataDictionary
• MVC的未来
• 将现有的Preview3应用程序升级到Preview 4 CodePlex Release
• 已知问题

简介

CodePlex Preview 4的发布包含了很多新的特性，并对默认项目模板进行了修改。对默认项目模板进行修改的目的是帮助启动最常见的应用程序构建场景。很多新特性都集中在简单的AJAX场景上。

What’s New

这一部分介绍了该发布版中新的和修改过的特性。

默认项目模板中的简单成员资格特性

很多Web应用程序都需要某种形式的用户验证。该发布版在默认项目模板中包含了一个AccountController类，用于处理下面这些用户操作：

• 登录
• 注销
• 注册
• 修改密码

默认项目模板的Web.config文件中包含了对MembershipProvider类的配置。这意味着当首次访问成员资格特性时，ASP.NET会自动创建一个SQL Server Express Edition成员资格数据库。你可以将SQL Server Express Edition数据库转换为SQL Server数据库，或修改Web.config文件中的连接字符串，使其指向一个现有的包含成员资格表的数据库。

默认模板中还包含Microsoft ASP.NET AJAX脚本文件的一个副本。我们一直在持续地为MVC版的ScriptManager控件进行工作；例如，我们使注册包含在嵌入资源中的脚本更加容易。然而，这些改进没有包含在这个发布版中。

用于授权和异常处理的过滤器类型

该发布版包含两种新的过滤器类型——授权过滤器和异常过滤器。尽管操作过滤器依然是最常见的过滤器类型，但我们希望提供能够在任意或者所有操作过滤器之前运行的过滤器，而不管过滤器的作用域。这样可以防止某些情形的出现，如在Authorization过滤器之前执行OutputCache过滤器，从而导致骗取授权。

为了支持新的过滤器类型，加入或修改了下列特性：

• 新的IAuthorizationFilter和IExceptionFilter接口。授权过滤器可以确保在所有其他操作过滤器之前运行。每个异常过滤器都会执行，即便是某个过滤器指明它已经处理了请求。这有助于记录和处理异常。
• AuthorizeAttribute类。这是IAuthorizationFilter的默认的具体实现。用于确保操作方法的安全。
• HandleErrorAttribute类。这是IExceptionFilter的默认的具体实现。用于处理异常并指定在发生异常时呈现哪个视图。
• 新的FilterAttribute基类。我们和新的过滤器类型一起引入了新的基类，这对所有过滤器特性都是有用的。

输出缓存过滤器

OutputCacheAttribute类是一个新的操作过滤器，用于使用内建的ASP.NET输出缓存来缓存操作方法的输出。

ASP.NET AJAX的变化

添加了下面的AJAX辅助方法。它们使用AjaxOptions类来指定异步操作的选项。

• ActionLink。该方法呈现一个指向某操作方法的锚标签。当单击该链接时，会异步地调用操作方法。该辅助方法的典型应用是通过指定AjaxOptions.UpdateTargetId属性获取响应并更新DOM元素。
• Form。该方法呈现一个可以异步提交的HTML表单。该辅助方法的典型应用是提交表单，和ActionLink类似，通过指定AjaxOptions.UpdateTargetId属性来获取响应并更新DOM元素。

我们将持续为ASP.NET MVC增强AJAX特性。这里提到的特性只是一个初级版本，我们希望在将来的发布版中能提供更强的特性。

路由的命名空间

在ASP.NET MVC之前的预览版中，框架会扫描所有程序集中的类型，以便找到控制器实现。然而，这样做偶尔会抛出异常，如某个类型是从一个尚未加载的程序集中的某个类型继承而来的，则框架在反射该类型时就会出错。

在这个发布中，我们提供了一种途径，能够为框架指定在尝试加载控制器类型时去检查哪些命名空间，这需要使用ControllerBuilder类的DefaultNamespaces属性。下面的示例展示了如何为解析控制器加载命名空间。

你也可以依次为每个路由指定命名空间。（在该发布版中，你还不能使用MapRoute扩展方法来做这件事。）下面的例子展示了如何为一个路由指定命名空间。

TempData的增强可测试性接口

在该发布版中，我们改进了可测试性，你可以使用会话Cookie而不是会话状态。添加了一个新的ITempDataProvider接口。默认情况下，控制器通过SessionStateTempDataProvider来访问会话状态，但现在可以实现其他的提供程序了。

ActionInvoker可扩展改进

添加了新的虚拟方法，在高级场景里你可以扩展调用器。下面的表格列出了新的方法。

ViewDataDictionary

我们对ViewDataDictionary进行了少许修改，将其索引器修改为一般索引器，并添加了Eval方法，用于对模型进行求值。

MVC的未来

ASP.NET MVC团队在日常的开发过程中，为很多特性建立了原型。这些特性有些会包含在RTM发布版中。如果没有包含进去，则可能会包含在未来的完整发布版中。我们将这些特性中的很多都放在了一个单独的MVC Futures项目中了。你会注意到项目模板包含并引用了一个名为Microsoft.Web.Mvc.dll的程序集，这就是MVC Futures项目的编译形式。

注意ComponentController和RenderComponent方法已经被替换成了MVC Futures项目中定义的RenderAction方法。RenderAction与普通的控制器协作，而不是特定的ComponentController对象。

对于该发布版，MVC Futures程序集（Microsoft.Web.Mvc.dll）被包含在了项目模板中，但在Beta和RTM发布版中就不会这样了。

将现有的Preview3应用程序升级到Preview 4 CodePlex Release

这一部分介绍了要想使使用Preview 3发布版创建的ASP.NET MVC应用程序能够运行在Preview 4发布版上，必须要对应用程序进行的修改。

• 更新对下列程序集的引用，使其指向新的Preview 4版本的程序集：
  • System.Web.Abstractions
  • System.Web.Routing
  • System.Web.Mvc

  默认情况下，这程序集位于下面的文件夹中：

  %ProgramFiles% \Microsoft ASP.NET\ASP.NET MVC CodePlex Preview 4

• 由于操作过滤器API有了些许改变，因此如果你编写了自定义的操作过滤器，你需要更新你的代码，匹配新的签名。
• 为了利用模板中的一些变化，你可能需要将模板的变化复制到你的项目中。

已知问题

• 在Medium信任下，在OutputCache过滤器上设置CacheProfile属性会抛出异常。
• 注意如果要在Visual Studio 2008速成版中使用ASP.NET MVC，你需要安装Visual Studio 2008 Express Edition SP1，位于：http://www.microsoft.com/downloads/details.aspx?FamilyId=BDB6391C-05CA-4036-9154-6DF4F6DEBD14&displaylang=en。与此相关的更多信息，请查看ScottGu的博客主题：http://weblogs.asp.net/scottgu/archive/2008/06/01/asp-net-mvc-support-with-visual-web-developer-2008-express.aspx。