发布日期：2009.06.15 作者：Anytao
© 2009 Anytao.com ，Anytao原创作品，转贴请注明作者和出处。

很早就有为《Silverlight 2完美征程》推荐的想法了，这源于我自己亲身经历的一点一滴。话说，关于Silverlight，TerryLee是我的导师和益友。他的系列文章《一步一步学Silverlight 2系列》为无数的Silverlight粉丝带来指导和导航，而我自己的Silverlight之路也是从这一系列文章开始的。现在，我很高兴的看到Terry的新书《Silverlight 2完美征程》隆重上市。

可以说，这本书继续了对《一步一步学Silverlight 2系列》的延续，全书22章包含了UI、控件、图像处理、动画效果等基本概念，以及数据绑定、网络通信、独立存储和浏览器交互等高级内容，全书的最后一些有意思的主题可以为我们的SIlverlight体验收获更多的美味，例如墨迹标注的使用、开发DeepZoom应用，凡此种种、无所不包。《Silverlight 2完美征程》就像是Silverlight的百科全书，涵盖了Silverlight主题的方方面面，在所有主题的论述中，我们始终能看到富有特色的Terry体，初学者很容易通过One By One式的引导来了解如何、怎样实现相应的功能；除了大量的实例实践，terry将他对技术的理解融入到实例的引导中，例如在网络通信章节的论述中，通过Silverlight与WCF、WebClient、HttpWebRequest以及最新的ADO .NET Data Service通信方式进行不同的通信体验，同时对跨域策略进行了深入的介绍，让读者能够更好的理解silverlight数据通信的深层原理。所以，毫不夸张的说，这是国内最优秀的Silverlight著作，源于国内最优秀的技术专家。

Terry是个认真博识的人，在我所认识的很多专家中，Terry始终保持着谦逊、认真和进取。每天和他的言谈身教，使我惊讶于他如此渊博的技术功底。我新历了他写作过程的艰辛、也感激他认真负责的写作态度，他的经历与能力让我毫不犹豫对《Silverlight 2完美征程》进行任何毫不掩饰的“吹捧”。

作为受益者，我拿起这本书为所有有Silverlight兴趣的朋友推荐，大家可以访问本书的官方网站：http://www.dotneteye.cn/silverlight，了解更多的信息。

更多精彩，尽在anytao.net

发布日期：2009.05.22 作者：Anytao
© 2009 Anytao.com ，Anytao原创作品，转贴请注明作者和出处。

/// <summary>
/// 本文开始，将以《.NET 4.0深入》为主线，开始一段体验.NET 4.0的激动旅程。
/// </summary>

总体来说，这是一篇介绍性的文章，不会涉及过多技术细节和研究过程。但是，作为拉开序幕的第一页，本文以提纲挈领的方式展开对.NET 4.0的初次体验。从What’s new的角度，开始我对.NET 4.0新特性的探索之旅。既然是介绍，那么首先给出导航式的链接是必要而必须的，因为一篇小小的篇幅却是难以交代全面What’s new in details，所以看官尽情各取所需吧：

• Visual Studio 2010 in MSDN
• What's New in Visual Studio 2010
• What's New in the .NET Framework 4
• .NET Framework 4 Beta 1
• Visual Studio 2010 Samples
• Visual Studio 2010 and .NET Framework 4 Training Kit
• Visual Studio 2010 Videos
• .NET Framework 4 Videos
• Visual Studio 2010 Beta 1 Walkthroughs

因为是[你必须知道的.NET]子系列，所以在此我只关注2010发布之后伴随.NET 4.0的新特性，总结起来主要包括以下几个方面：

• CLR (Common Language Runtime)
• DLR (Dynamic Language Runtime)
• C# and VB .NET
• Web and Networking
• Basic class libraries(BCL)
• Data
• Client
• Web
• Communications

所以，对what’s new的解读，我将分为两个大的部分来诠释：

• Hot Focus，热点解读。对新特性中值得期待和关注的技术点进行一点整理，因为太多太多了，所以学会抽丝拨茧才是正确之道，在Hot Focus中我们首先对亮点进行一番认知。同时，Hot Focus内容体系也将是为了《深入.NET 4.0》子系列探索的方向和大纲。
• Full View，.NET 4.0全景图。把概念涉及到各个新增的方面，由此对.NET4.0有个全面和基本的了解。

Hot Focus

在我看来，值得Hot Focus的主要包括以下几个方面：

• CLR & DLR
• C#
• Web
• Cloud
• Data
• F#

下面进行一一分解。

CLR 4.0

是的，不用怀疑，CLR 4.0来了，从CLR 2.0一跃升级到CLR 4.0，我们对新建项目进行反编译，即可从Manifest中获取当前CLR的版本信息，例如：

可见没有重量级的新成员，.NET产品组是不敢贸然为新生儿挂上如此响亮的封号。那么这个分量足够的新家伙到底是谁呢？

答案是：

• DLR（Dynamic Language Runtime），动态语言运行时，提供了对动态语言在CLR级别的支持。
• Parallel Computing，并行计算，在多核时代，并行计算已经不可避免。新的平台下，对于并行的支持也随之而来，我们不需要在直接对线程进行管理，Parallel和Task类，当然还有PLINQ（Parallel LINQ）都将闪亮登场。
• GC，GC也有新变化，我们拭目以待。
• Convariance and Contravariance，逆变与协变，解决了泛型继承的某些问题，算是一场迟来的完善。
• Interoperability，互操作将不依赖于原有的RIAs，新的CLR确保了类型安全操作。
• Lazy Initialization，在未来的日子，通过System.Lazy<T>来为你的实例提供延迟初始化成为可能，这将意味着你的类型可以在实际需要的时候才进行实例化操作、分配内存空间，对性能的控制达到了新的高度。
• In-Process Side-by-Side Execution，In-Process Side-by-Side hosting解决了不同版本应用在CLR 4.0平台下运行的问题，我们以后详细讨论。

除此之外，还包括：

• Security
• ETW Events
• Code Contracts
• Profiling

所有的概念，我们都将随后品味。那是因为，所有的概念都是重量级的。

C# 4.0

C# 4.0主要引入了以下程序元素：

• Office Programmability
• Dynamic
• Covariance and Contravariance
• Type Equivalence

关于.NET 4.0和C# 4.0的若干概念，我在[[你必须知道的.NET]第三十回：.NET十年（下）]已经进行过介绍性的演示与探讨，大家不妨一睹为快。

ASP .NET 4.0

What's New in ASP.NET and Web Development

对于Web开发而言, ASP .NET 4.0从3.5开始就已经提供了很多未集成的新东西，其中包括了类似于MVC在内的很多了不起的改变。所以，对于.NET 4.0而言，我们对于Web开发的贡献，在于对过去的整理和再生，值得关注的内容主要包括：

• MVC，虽然VS2010 Beta1还没有将MVC Framework整合在内，但是微软承诺在Beta2中我们就可以看到新的MVC身影。
• Dynamic Data，对，早已领略了如何一分钟之内开发一个增删改查式的动态站点，在ASP .NET 4.0中实现数据驱动的Web开发更加Powerful了。
• Web Form，在ASP .NET 4.0传统的Web Form开发被注入了更多的新特性，我们可以像MVC Application那样无缝的使用ASP .NET Routing，对于数据源提供了Filtering支持，更多的View state控制，还有好多好多。。。
• EntityDataSource Control，支持基于Entity Framework的数据绑定控制。

还有很多，详见What's New in ASP.NET and Web Development

Data

What's New in ADO.NET

在数据方面主要还是ADO .NET Entity Framework的增强和Expression Tree的更多支持。EF主要体现在以下方面：

• Persistence-Ignorant Objects，这个特性是令人欢欣鼓舞的，在新的EF框架下，EF实体类和非EF实体类都应用EF提供的数据支持，这将意味着原有的数据模型也可以畅享EF了。
• Deferred Loading of Related Objects，如果你没有体会过原来EF处理延迟加载使用的方式时：

if (!user.RoleReference.IsLoaded)
{
    user.RoleReference.Load();
}

是很难理解，这一新特性为代码优化给出了机会。

• Functions in LINQ to Entities Queries，一切皆LINQ的时代，这点也不奇怪。
• Customized Object Layer Code Generation，为EF数据设计器提供了自动生成代码的可配置向导，更加人性化的选择。
• 还包括：Complex Type Support、Naming Service、Improved Model Brower Funcationality。

另外，对于Expression Tree，控制了几个新的类型支持，例如 LoopExpression 和TryExpression。

BCL

基础类库的更新，是每次.NET版本更新的重要内容，.NET 4.0中基础类库的新增内容，同样惊为天人。在此我仅列举几个重要的更新，更多的内容参考MSDN。

• Collections
  • BigInterger
  • SortedSet<T>
  • Tuples
• I/O
  • File System Enumeration
  • Memory-Mapped Files
  • Isolated Storage
  • Compression
• Exception
• Reflection
• 64-bit
• Application Domain Resource Monitoring
• Threading
• Unified Model for Cancellation
• Thread-Safe Collection
• Synchronization Primitives
• 。。。
• 。。。
• 很多很多，我们的策略显然是随用随取。

Cloud

云计算将不可避免的到来，在.NET 4.0平台下，Azure Service应用将眼花缭乱，但是可以肯定的是开发模式更加简化，大量的问题需要时间在以后，我们到时再来掂量一二。

F#

一个对我全新而又有足够吸引力的新语言，以后再说吧:-)

Full View

除了以上的重点内容，作为.NET 4.0大家族的一部分，还有很多很多令人兴奋的新东西加入进来，令我们叹息一切太多太快的同时，又带来一丝丝惊喜和心动。废话少说，对其进行一番简单的整理：

• MEF
• WPF
• WCF 4.0
• WF 4.0
• Appliction Server（代号Dublin）

结论

.NET 4.0来了，在这个夏天。在蚊子和啤酒相伴的深夜，我将继续[你必须知道的.NET] 系列的完善，将自己对于.NET 4.0新特性的探索形成[深入.NET 4.0]这样一个子系列。同样是一如既往的将角度把握在语言和平台本质的探索，可能的角度上，最佳实践式的应用和国外最新论调的共享同样是这一新生力量关注的话题。好戏才刚开始，我们继续在路上。

注：你必须知道的.NET, .NET 4.0子系列以VS2010 Beta1和.NET 4.0 Beta1为基础，任何后续更新造成的可能不同，我将尽力完善。 

参考文献

• Visual Studio 2010 in MSDN
• What's New in Visual Studio 2010
• What's New in the .NET Framework 4
• .NET Framework 4 Beta 1
• Visual Studio 2010 Samples
• Visual Studio 2010 and .NET Framework 4 Training Kit
• Visual Studio 2010 Videos
• .NET Framework 4 Videos
• Visual Studio 2010 Beta 1 Walkthroughs

更多精彩，尽在anytao.net

发布日期：2009.05.11 作者：Anytao
© 2009 Anytao.com ，Anytao原创作品，转贴请注明作者和出处。

/// <summary>
/// 本文部分内容，已发表于《程序员》杂志第二期《C#，语言的变迁》
/// </summary>

引言

语言是程序开发者行走江湖的手上利器，各大门派的高手在论坛、博客为了自家门派争吵不已早是技术世界中的亮丽风景，虽多少为刚刚踏入江湖的新手提供了思考的素材，但也同时迷惑了初出茅庐的前行方向。

本文不欲计较门派的高下，旨在明辨技术的真谛，这就是.NET平台下的开发利器：C#语言，并从其变迁的进程中对于.NET技术发展把玩一番。

在下篇，我们将从历史走来，对.NET的未来做个展望性的了解，具体而言就是.NET 4.0的新东西。

.NET之，未来武器

无论如何，.NET 4.0已经在叩开新年的大门之时，以高调的姿态迎来一片掌声。广大的技术爱好者不会等待太长的时间，就能感受C#发展中的又一次变革。随着.NET 4.0在2009年的发布，我们对于C# 4.0的关注也将与日俱增。总体而言，C# 4.0的重头戏主要着眼在以下几个方面：

• 动态编程
• 并行计算
• 后期绑定
• 协变与逆变

废话少说，接下来我们一一领略C# 4.0中的语言特性。

动态编程

众所周知，C#是静态强类型语言。而在很多情况下，提供“动态”行为，是常常发生的事情，例如通过反射在运行时访问.NET类型、调用动态语言对象、访问COM对象等，都无法以静态类型来获取。因此， C# 4.0引入的又一个全新的关键字dynamic，也同时引入了改善静态类型与动态对象的交互能力，这就是动态查找（Dynamic Lookup）例如：

// Release : code06, 2009/05/07
// Author  : Anytao, http://www.anytao.com
public static void Main()
{
     dynamic d = GetDynamicObject();               
     d.MyMethod(22);                  // 方法调用   
    d.A = d.B;                       // 属性赋值
    d[“one”] = d[“two”];             // 索引器赋值
    int i = d + 100;                 // 运算符调用
    string s = d(1,2);               // 委托调用
}

就像一个object可以代表任何类型，dynamic使得类型决断在运行时进行，方法调用、属性访问、委托调用都可动态分派。同时，动态特性还体现在构建一个动态对象，在C# 4.0实现IDynamicObject接口的类型，可以完全定义动态操作的意义，通过将C#编译器作为运行时组件来完成由静态编译器延迟的操作，例如：

dynamic d = new Foo();  
string s;   
  
d.MyMethod(s, 3, null);

在具体执行过程中，C#的运行时绑定器基于运行时信息，通过反射获取d的实际类型Foo，然后在Foo类型上就MyMethod方法进行方法查找和重载解析，并执行调用，这正是动态调用的背后秘密：DLR。在.NET 4.0中将引入重要的底层组件DLR（Dynamic Language Runtime，动态语言运行时），除了实现动态查找的基础支持，DLR也同时作为基础设施为类似于IronRuby、IronPython这样的动态语言提供统一的互操作机制。总而言之，动态编程将为C#在以下领域产生巨大的变革：

• Office编程与其他COM交互。
• 动态语言支持，在C#中消费IronRuby动态语言类型将并非难事，体验动态语言特性指日可待。
• 增强反射支持。

以调用IronRython为例，我们只需引入IronPython.dll, IronPython.Modules.dll, and Microsoft.Scripting.dll，即可通过创建ScriptRuntime在C#中HostingIronPython环境，进而来操作动态语言的类型信息。

ScriptRuntime py = Python.CreateRuntime();
dynamic mypy = py.UseFile("myfile.py");

Console.WriteLine(mypy.MyMethod("Hello"));

虽然从微软当前提供的技术资料和CTP演示中，动态查找还存在或多或少的问题，但是在“动态”大行其道的今天，我们无法回避也必须拥抱这个未来的主角，因为我坚信明天会更好。

并行计算

并行计算的出现，是计算机科学发展的必然结果，随着计算机硬件的迅猛发展，在多核处理器上工作已经是既存事实，而传统的编程模式必须兼容新的硬件环境才能使计算机性能达到合理的应用效果。用Anders大师的话说：未来5到10年，并行计算将成为主流编程语言不可忽视的方向，而4.0为C#打响了实现并发的第一枪。

未来的.NET Framework 4.0中将集成TPL（Task Parallel Library）和PLINQ（Parallel LINQ），这也意味着未来我们可以应用C# 4.0实现并行化应用，在统一的工作调度程序下进行硬件的并行协调，这将大大提高应用程序的性能同时降低现存并发模型的复杂性。

那么，我们应该一睹为快应用C#武器来开发并发环境下的超酷感受，在System.Threading.Parallel 静态类提供了三个重要的方法For、Foreach、Invoke可以为我们小试牛刀：

//应用TPL，执行并行循环任务
Parallel.For(0, 10, i =>
{
    DoSomething(i);
});

在线程争用执行情况下，相同的操作在双核平台下运行，以StopWatch进行精确时间测试，并行环境下的执行时间为 2001ms，而非并行环境下的执行时间为4500ms，并行运算的魅力果然名不虚传。我们再接再厉应用PLINQ执行对于并行运算的查询、排序等，当前PLINQ支持两种方式ParallelEnumerable类和ParallelQuery类，例如：

int[] data = new int[] { 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 };
int[] selected = (from x in data.AsParallel()
                  select x + 1).ToArray();

更详细的对比示例留待读者在实践中对此进行讨论，并行计算为托管代码在多核环境下的性能优化提供了统一的解决方案，而未来我们会做的更好。

备注：实际上，我们可以选择下载安装Microsoft Parallel Extensions to the .NET Framework 3.5June 2008 CTP包，就可以在.NET 3.5环境下体验并行计算的无穷魅力。

协变和逆变

协变和逆变，是为解决问题而生的。而要理清解决什么样的问题，需要首先从理清几个简单的概念开始。首先我们进行一点操作：

Derived d = new Derived();
Base b = d;

Derived类型继承自Based类型，由Derived引用可以安全的转换为Based引用，而这种转换能力可以无缝的实现在Derived数组和Base数组，例如：

Derived[] ds = new Derived[5];
Base[] bs = ds;

而这种原始转换（由子类转换为父类）方向相同的可变性，被称为协变（covariant）；其反向操作则被称为逆变（contravariant）。当同样的情形应用于泛型时，例如：

List<Derived> ds = new List<Derived>();
List<Base> bs = ds;

类似的操作却是行不通的。所以，这就成为C# 4.0中完善的问题——泛型的协变与逆变：

// Release : code07, 2009/05/07
// Author  : Anytao, http://www.anytao.com
List<Base> bs = new List<Base>();
List<Derived> ds = new List<Derived>();

bs = ds;    //List<T>支持对T协变
ds = bs;    //List<T>支持对T逆变

而在C# 4.0中，伴随着协变与逆变特性的加入，C#引入两个in和out关键字来解决问题。

// Release : code08, 2009/05/07
// Author  : Anytao, http://www.anytao.com
public interface ICovariant<out T>
{
    T MyAction();
}

public interface IContravariant<in T>
{
    void MyAction(T arg);
}

其中，out表示仅能作为返回值的类型参数，而in表示仅能作为参数的类型参数，不过一个接口可以既有out又有in，因此既可以支持协变、支持逆变，也可以同时支持，例如：

public interface IBoth<out U, in V>
{
}

命名参数和可选参数

命名参数和可选参数是两个比较简单的特性，对于熟悉其他编程语言的开发者来说可选参数并不陌生，为参数提供默认值时就是可选参数：

// Release : code09, 2009/05/07
// Author  : Anytao, http://www.anytao.com
public void MyMethod(int x, int y = 10, int z = 100)
{
}

因此，我们可以通过调用MyMethod(1)、MyMethod(1, 2)方式来调用MyMethod方法。而命名参数解决的是传递实参时，避免因为省去默认参数造成的重载问题，例如省去第二个参数y调用时，即可通过声明参数名称的方式来传递：

MyMethod(20, z: 200);

相当于调用MyMethod(20, 10, 200)，非常类似于Attribute的调用方式。虽然只是小技巧，但也同时改善了方法重载的灵活性和适配性，体现了C#语言日趋完美的发展轨迹。

当然，除此之外.NET 4.0还增加了很多值得期待的平台特性，也将为C#编码带来前所未有的新体验。

.NET之，趋势不可逆转

预测未来，在技术世界是常有的事儿。从高级语言的发展历史来看，编程世界从来就没有停止过脚步，变革时时发生、创新处处存在。以技术人员的角度来观摩未来，带着C# 4.0的脚步来看展望， 除了在函数式编程、并行计算和动态特性上大展拳脚，Meta Programming的概念已然浮出水面，将编译器变成一个Service，你可以自由控制在编译器和运行期的逻辑，那是多么美好而向往的未来呀，所以，我们坚信 4.0之后还有广阔的天地随着语言的变迁变得更加开阔。

概括Anders大师在C#设计过程中的思想，C#是语言美学的集大成者。例如，当使用foreach进行循环遍历之后，当应用using语句代替try/finally实现强制资源管理，当应该attribute进行运行时反射，当以LINQ进行语言级别的信息查询，这些语言级别的支持为C#实现面向对象编程带来强大的功能动力和美学感受。

注：本文代码在VS2010 CTP基础上开发，未检测任何版本更新所带来的不同，望明察。

参考文献

（Web）http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

（Web）http://weblogs.asp.net/podwysocki/archive/2008/05/24/what-is-the-future-of-c-anyways.aspx

（Web）New features in C# 4.0

（Web）http://msdn.microsoft.com/en-us/magazine/cc163340.aspx

作者简介：

王涛，网名Anytao，微软C# MVP，高级软件工程师，机械工程硕士，《你必须知道的.NET》一书作者，主要研究方向为.NET底层架构和企业级系统应用。现就职于某软件公司负责架构设计、软件开发和项目管理方面的工作。作者对.NET基础架构和CLR底层运行机制有浓厚的研究兴趣和造诣，熟悉ASP.NET、XML、WCF、SQL Server相关技术，对面向对象、设计模式和软件架构有一定的研究与实践经验。他的联系方式如下：http://www.cnblogs.com/Anytao

更多精彩，尽在anytao.net

发布日期：2009.05.08 作者：Anytao
© 2009 Anytao.com ，Anytao原创作品，转贴请注明作者和出处。

/// <summary>
/// 本文部分内容，已发表于《程序员》杂志第二期《C#，语言的变迁》
/// </summary>

引言

语言是程序开发者行走江湖的手上利器，各大门派的高手在论坛、博客为了自家门派争吵不已早是技术世界中的亮丽风景，虽多少为刚刚踏入江湖的新手提供了思考的素材，但也同时迷惑了初出茅庐的前行方向。

本文不欲计较门派的高下，旨在明辨技术的真谛，这就是.NET平台下的开发利器：C#语言，并从其变迁的进程中对于.NET技术发展把玩一番。

在上篇，我们走在历史，对.NET的过去尤其是c#语言做以回顾，具体而言就是.NET 1.0、2.0、3.0的一路走来。

.NET之，历史脚步

C#十年了。这个日期是从Anders Hejlsberg在1998年组建C#团队开始算起的，掐指算来已是十年有余了。作为.NET平台下的静态强类型语言，在过去10年的发展历程中披荆斩棘，已经逐渐成为应用开发语言中的佼佼者。从TIOBE开发语言排行榜的最新统计来看，C#位居第六成为开发语言市场的顶级产品：

表 1 TIOBE开发语言排行榜

（注：此为2008年12月的TIOBE开发语言排行榜，参考http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html）

因此，在我们讲解历史的开始，将C#发展历史中的里程碑作以标记，来感受一下C# 10年的发展历程，为每开发者在心底搭起一座通往未来的桥梁。

下面我们分别从不同的历史阶段来了解C#语言的变迁，并讨论在每个变迁的里程碑上值得品味的闪光点，并由此为未来的发展打一个基础。

1.0，从诞生到立足

2000年之夏，微软大当家­­——盖茨先生着手战略调整，微软大刀阔斧的进行了技术改革与创新，并由此为世界带来一个新的名词，这就是.NET。那么什么是.NET呢？在.NET这一概念诞生之初，这一概念连微软本身都充满了定位的错乱和迷茫，以至于一时之间处处皆为.NET，大有一统江湖之势。随着.NET平台的逐渐完善，概念和定位上的混乱已经日渐清晰，作为这场变革中的一项重要内容，一种全新的、能够适应.NET平台特性的高级语言C#也随之诞生。这一任务理所当然的落在了Anders Hejlsberg的身上，作为Delphi之父，大师级的Anders从1998年11月开始领导了他的小组为这个世界带来全新的语言宠儿，这就是：C#。

初出茅庐的C#，就像羞羞答答的小姑娘，步步留心、时时在意，学着他人的模样，生怕在前辈面前丢脸。当她以全新的姿态出现在万千程序开发者眼前时，其兼取百家之长、优雅简洁之态、摒弃复杂之弊的特性，立时令所有的观望折服。在迎来所有目光的关注的同时，迅速成为高级语言战场的骄子。

那么，C#诞生之初兼取百家之长，具体都有哪些优秀品质呢，总结起来主要体现在两个方面包括：

• 面向对象编程。C#实现对属性、事件、委托、方法、索引器、构造器的全面支持，为面向对象的封装、继承、多态和接口提供了语言级别的支持。以继承为例，c#支持单实现继承和多接口继承，摒弃了C++中多继承带来的复杂性。
• 跨平台运行时支持。CLR是.NET平台下应用程序的通用语言运行时，是C#程序赖以生存的跨平台环境，因此C#具有了.NET平台语言的所有优势，通用类型系统、自动内存管理、统一异常处理、完全的FCL访问权，都成为C#无与伦比的优势所在。

2.0，变革之作

C# 2.0是一次完善和补充，也是一次变革与重生。在2.0中引入了诸多的语言特性，完善了1.0基础上的某些不足，例如匿名方法将代码放在委托而无需创建新的方法；可空类型实现了对值类型的null操作；而部分类将一个类分解到多个类文件中。这些补充和完善， 总结起来主要包括：

• 匿名方法
• 可空类型
• 部分类
• 迭代器
• 泛型

其中，泛型支持是C# 2.0的重中之重，.NET框架从CLR级别实现了对泛型的支持，提供专门的IL指令支持泛型操作，同时配合C#语言机制构造一种全新的编程结构，实现了对类型抽象化的通用处理方式，这就是算法重用。

以最简单的交换数据为例，我们来了解泛型带来的好处：

// Release : code01, 2009/05/07
// Author  : Anytao, http://www.anytao.com
public static void Swap(ref int x, ref int y)
{
    int temp = x;
    x = y;
    y = temp;
}

public static void Swap(ref string str1, ref string str2)
{
    string temp = str1;
    str1 = str2;
    str2 = temp;
}

以上两种算法分别实现了对整型、字符串型数据的交换，在泛型引入之前实现相同的交换算法需要分别为所有的类型构建相似的处理逻辑，这显然是一种代码上的浪费，而泛型特性彻底解决了这一问题：

// Release : code02, 2009/05/07
// Author  : Anytao, http://www.anytao.com
public static void Swap<T>(ref T t1, ref T t2)
{
    T temp = t1;
    t1 = t2;
    t2 = temp;
}

对于不同的类型，在运行时以实际类型对T占位符进行替换，并转换为本地代码，彻底实现了灵活的类型抽象和算法重用。同时，除了代码级别的重用好处，泛型解决了类型转换、装箱与拆箱、类型安全等诸多问题，为程序设计带来巨大的变革。

3.0，涅槃与重生

C# 3.0是语言发展历史上的里程碑变革，就像凤凰涅槃一般为C#语言注入强大编程体验和活力，简洁、干净、富有意义，这些特性中主要包括：

• 匿名类型
• 自动属性
• 对象初始化器
• 集合初始化器
• 隐式类型变量和隐式类型数组
• 扩展方法
• 查询表达式

除此之外，C# 3.0的最大亮点就是LINQ（Language Integrated Query，语言集成查询），在CLR中集成类似于SQL式的数据查询能力，一种前所未有的函数式编程体验在面向对象语言中得以大展拳脚，这不得不说是C#带来的超酷体验。

因为，本文并非一本讲述编程的教科书，所以我们无法在有限的篇幅来展现优雅的代码，只能取一瓢饮之，并通过简要的对比来领略3.0中的强大功能。以对象初始化器为例，在2.0时初始化对象成员，我们以这种方式实现：

User user = new User();
user.Name = "小王";
user.Age = 28;

在3.0中，实现对象初始化有了更好的解决方案，由对象初始化器来完成：

User user = new User { Name = "小王", Age = 28 };

同样的方式可以用来实现集合的初始化和隐式类型的初始化等。

接着，我们再来了解一下自动属性带来的语法魅力，在3.0之前进行属性封装的是一件麻烦的事情，例如：

// Release : code03, 2009/05/07
// Author  : Anytao, http://www.anytao.com
class User
{
    private string name;
    public string Name
    {
        get { return name; }
    }

    private int age;
    public int Age
    {
        get { return age; }
        set { age = value; }
    }
}

而自动属性将这一切化简为无形，语法简单而功能依旧：

// Release : code04, 2009/05/07
// Author  : Anytao, http://www.anytao.com
public class User
{
    public string Name { get; set; }
    public int Age { get; set; }
}

这些所有的新特性最终都为了一个共同的目标而铺垫，这就是C# 3.0中最重量级的新特性：LINQ。所以，本文也不能少了对LINQ的讨论，在代码级别实现类似于SQL式的查询语法，以类型安全的通用方式完成增、删、改、查等数据操作的基本方式。只要数据源基于IEnumerable<T>接口而实现，那么不管是关系型数据、内存中集合还是XML都可以作为LINQ查询对象进行数据处理，这为面向对象语言实现函数式的编程体验创造了条件，一种全新的编程风格为编程体验刮来一股旋风：

// Release : code05, 2009/05/07
// Author  : Anytao, http://www.anytao.com
public static void Main()
{
    List<User> users = new List<User>
    {
        new User{Name = "小王", Age = 27},
        new User{Name = "小张", Age = 29},
        new User{Name = "小李", Age = 23}
    };

    IEnumerable<User> result = from user in users
                               where user.Age < 30
                               orderby user.Age descending
                               select user;

    foreach (var user in result)
    {
        //执行操作
    }
}

你看，这种体验果然非同凡响，优雅而简单没有辜负Anders对于代码美学的追求。而作为编程用户，我们同样体味了这种理念在功能和结构上的双重精彩。

参考文献

（Web）http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

（Web）http://weblogs.asp.net/podwysocki/archive/2008/05/24/what-is-the-future-of-c-anyways.aspx

（Web）New features in C# 4.0

（Web）http://msdn.microsoft.com/en-us/magazine/cc163340.aspx

作者简介：

王涛，网名Anytao，微软C# MVP，高级软件工程师，机械工程硕士，《你必须知道的.NET》一书作者，主要研究方向为.NET底层架构和企业级系统应用。现就职于某软件公司负责架构设计、软件开发和项目管理方面的工作。作者对.NET基础架构和CLR底层运行机制有浓厚的研究兴趣和造诣，熟悉ASP.NET、XML、WCF、SQL Server相关技术，对面向对象、设计模式和软件架构有一定的研究与实践经验。他的联系方式如下：http://www.cnblogs.com/Anytao

更多精彩，尽在anytao.net

发布日期：2009.05.06 作者：Anytao
© 2009 Anytao.com ，Anytao原创作品，转贴请注明作者和出处。

对HtmlHelper进行扩展，是MVC中对于View层进行灵活控制的主要手段之一，对此我在第七回：漫谈ActionLink，有时“胡搅蛮缠”中进行过探讨。在本文，只是一个小技巧，丰富我们在自定义HtmlHelper时可以有更好的选择。

首先，我们先了解一下，几个简单的HtmlHelper扩展是如何实现：

public static string Label(this HtmlHelper helper, string name, string value)
{
    return string.Format("<label for='{0}'>{1}</label><br />", name, value);
}

很简单，就是实现一个对HtmlHelper的扩展方法，这样我们就可以在View层通过

<%= Html.Label("Anytao", "tao") %>

而无需：

<label for="tao">Anytao</label>

显然，通过Html.Lable方式更加的简洁和灵活，此例仅仅是个简单的举例。事实上，通过Html.XXX可以封装更多的预定义Html代码，实现更多有效、复杂的个性化实现，例如在本文的下一篇我将通过Html.Naviagte方式实现一个封装了Sitemap的Breadcrumb控制，从而使得我们体会更好的Html是如何做到的。

对于Html.Label而言，还有一个重要的内容需要添加，那就是对于Html标记如何动态的指定和渲染，例如我们可以对Label指定id、class还有更多其他的Html属性，这是个有市场的需求，因为至少为Dom元素指定Css是经常发生的事情，例如假设有如下的需求：

<label class="grey" for="tao">Anytao</label>

在原有的Html.Label扩展实现中，class的指定是无法做到的，因此需要从新构造，办法就是添加htmlAttributes参数，实现类似于ActionLink一样的控制，例如：

<%= Html.Label("Anytao", "tao", new { @class="grey"} %>

那么，我们该如何办呢？我想起了TagBuilder，来简化实现的复杂度，事实上TagBuilder就是干这个的主，废话不说给出更新之后的Html.Label实现：

public static string Label(this HtmlHelper helper, string name, string value, object htmlAttributes)
{
    TagBuilder tagBuilder = new TagBuilder("label")
    {
        InnerHtml = value
    };
    tagBuilder.MergeAttribute("for", name);
    tagBuilder.MergeAttributes(new RouteValueDictionary(htmlAttributes));
    return tagBuilder.ToString(TagRenderMode.Normal);
}

办法很简单，在Html.Label内部通过TagBuilder，实现了对htmlAttribute特性的添加，实现的办法非常简单：

tagBuilder.MergeAttributes(new RouteValueDictionary(htmlAttributes));

在MergeAttributes方法内部实现对Html Attribute信息的整合，有兴趣大家可以了解具体的实现规则。

既然我们的主角是TagBuilder，那么就顺便近看其面目，总体来说TagBuilder就是创建Html标签的Builder，类似于StringBuilder封装了对Html标签的很多简单而有效的方法（例如MergeAttributes），主要包括：

• AddCssClass
• GenerateId
• MergeAttribute
• SetInnerText
• ToString

还包括几个属性：

• Attributes
• IdAttributeDotReplacement
• InnerHtml
• TagName

工欲善其事，必先利其器。TagBuidler使得HtmlHelper变得简单，自信的观众可以完全不用TagBuilder，通过任何其他的办法来实现类似于MergeAttribute、AddCssClass这样的逻辑，但是既然已经有了，不妨一试。就像它的大哥StringBuilder，给我们处理string带来多少不错的亲近感受，看面子也不妨关照一下小弟TagBuilder。

更多精彩，尽在anytao.net

发布日期：2009.04.30 作者：Anytao
© 2009 Anytao.com ，Anytao原创作品，转贴请注明作者和出处。

MVC时代来临了，但是一开始是不被很多人接受的。可能的主要原因是，大家不得不告别拖拉控件的至爽感受，回到貌似asp的历史岁月。所以，心有不甘是可以理解的，然而时代显然是进步的。我们虽然必须在View中进行很多HTML代码的工作，但是MVC为我们提供了可以堪称完美的方案（至少我是这样认为的），那就是HtmlHelper。在MVC的View层，我们有很多熟悉的面孔，例如Html.Encode、Html.AntiForgeryToken、Html.BeginForm、Html.TextBox等，而其中ActionLink算是其中的“猛将兄”。

浅议HtmlHelper

简单的说，HtmlHelper就是一个封装了ViewContext、IViewDataContainer、RouteCollection等上下文信息的一箩筐静态方法类（注，HtmlHelper本身并不是静态类），其中包含了我们上文介绍的熟悉身影Encode、AntiForgeryToken等，但不包含BeginForm、TextBox，当然也不包括ActionLink，其原因是BeginForm、TextBox、ActionLink其实是HtmlHelper的扩展方法，我们可以从智能感知提示中最直观的得到了解：

显然，ActionLink和Encode的智能提示标记是有区别的。

所以，HtmlHelper其实很简单，而通过Extension Methods对其的“功能注入”机制实现了极大的扩展空间。而且，HtmlHelper封装了ViewContext、RouteCollection等上下文信息，为实现扩展带来便利。所以，顺便提一下，这也正是老赵同志在为视图自定义辅助方法（上）中实现JQueryHelper时引入相应元素（ViewContext、RouteCollection、ViewPage），有着异曲同工之妙，所以HtmlHelper并不是唯一的选择，高兴的话，你也可以类似于AnytaoHelper之类的东东。

所以，通过HtmlHelper就可在运行时动态生成HTML代码，其实我们在WebForm时代就经常玩儿这种“阴招”，然而在HtmlHelper这里，显然已经发扬光大了。例如老赵的JQueryHelper就通过一系列的包装，省去了对validation的麻烦语法。

同时，扩展HtmlHelper其实及其简单。例如：

// Release : code01, 2009/04/30
// Author  : Anytao, http://www.anytao.com
public static string Label(this HtmlHelper helper, string name, string value)
{
    return string.Format("<label for='{0}'>{1}</label><br />", name, value);
}

通过下面的方式就可以调用该方法了：

<%= Html.Label("name", "Tao") %>

同样的道理，当我们摊开ActionLink的实现具体实现时，可见：

public static string ActionLink(this AjaxHelper ajaxHelper, string linkText, string actionName, string controllerName, RouteValueDictionary routeValues, AjaxOptions ajaxOptions, IDictionary<string, object> htmlAttributes) {
    if (String.IsNullOrEmpty(linkText)) {
        throw new ArgumentException(MvcResources.Common_NullOrEmpty, "linkText");
    }

    string targetUrl = UrlHelper.GenerateUrl(null, actionName, controllerName, routeValues, ajaxHelper.RouteCollection, ajaxHelper.ViewContext.RequestContext, true /* includeImplicitMvcValues */);

    return GenerateLink(linkText, targetUrl, GetAjaxOptions(ajaxOptions), htmlAttributes);
}

有时“胡搅蛮缠”

聊了半天HtmlHelper，该说说ActionLink了。正如前文而言，ActionLink仅仅是HtmlHelper的扩展方法而已。不过，虽然ActionLink平易近人，但是还是在不经意间发现其胡搅蛮缠的地方。我们先按下不表来看看如何使用ActionLinks，MVC Framework为我们提供了两种方式：

• ActionLink
• ActionLink<TController>

显而易见，一种是非泛型方法，通过参数方式调用，没有强类型优势；另一种是泛型方法，可以通过强类型调用，不过如果通过ActionName对Action进行重写标记时，泛型ActionLink<TController>是不可用的，我在《还是ActionFilter，实现对业务逻辑的统一Authorize处理》已进行过讨论了。

<%=Html.ActionLink("Edit", "Edit", "Book", new { id = Model.ID }, new { @class = "BookDetail"})%>

具体而言，上述参数主要包括：

• Edit，为linkText，具体而言就是显示的字符串；
• Edit，对应为ActionName；
• Book，为Controller；
• new { id = Model.ID }，为生成元素的id定义；
• new { @class = “BookDetail” }，则为元素添加了tag要素。

具体的执行逻辑不是我们关心的问题，而上述代码生成的Source Code，则对应为：

<a class="BookDetail" href="/Book/Edit/1">Edit</a>

而如果应用泛型ActionLink，则上述调用将变成：

<%= Html.ActionLink<BookController>(c => c.Detail(), "Edit") %>

生成同样的Source Code，不过通常情况下，我们还是推荐泛型ActionLink，至少有类型安全、代码优雅的优点。

注：既然是ActionLink，文如其名，我们不能将其滥用，也就是说涉及Action的Links时可以考虑用ActionLink，其他情况下最好还是手写自己的链接代码或者扩展自己的HtmlHelper等。

然而，在有些情况下，假设我们有如下Route：

// Release : code02, 2009/04/30
// Author  : Anytao, http://www.anytao.com
routes.MapRoute(
    "BookRoute",
    "Tao/Book/id",
    new { controller = "Book", action = "Detail", id = "" }
    );

当我们使用

<%= Html.ActionLink("Book", "Detail", "Book", null, null) %>

调用BookController下的Detail Action，不过令我们奇怪的是，生成Html代码并不如期望的那样，而是：

<a href="/Tao/Book/id">Book</a>

显然，ActionLink有点儿“胡搅蛮缠”了。其原因在于，新定义的BookRoute改写了ActionLink的“既有”行为，本来我们期望的是：

<a href="/Book/Detail/id">Book</a>

为了追查原因，我们将对ActionLink进行了必要的调查，首先了解ActionLink的定义：

public static string ActionLink(this HtmlHelper htmlHelper, string linkText, string actionName)

而ActionLink的具体实现中，我们看到了routeCollection的GetVirtualPath方法中涉及了对">">Dictionary<string, RouteBase>的操作，所以不言而喻，ActionLink生成的Url是受routeCollection影响的。对于其“胡搅蛮缠”，我相信这就是原因吧。

所以，虽是一个小小的意外，但是了解了就不是意外。对于我们的应用而言，有两点值得注意：

• 注意Route定义对于ActionLink可能造成的影响。
• 在这种情况下，我们可以考虑放弃ActionLink，而通过全手动方式实现：

<a href="Book/Detail/<%= Model.ID %>">Book</a>

不偿为一种回归原始的方式，不是吗？

本文调侃了题目，但是更重要的事情是我们对HtmlHelper及ActionLink有了个大致的了解，对于更好的应用是有好处的。那么，今天就说到这里。

代码下载，这里。更多关注，尽在anytao.net/blog

发布日期：2009.04.29 作者：Anytao
© 2009 Anytao.com ，Anytao原创作品，转贴请注明作者和出处。

MVC是个新鲜的东西，至少为ASP .NET Web世界带来或多或少的争议，褒奖者有之，诋毁者有之。这也正常，人类的思维确实没法统一，即便是多个选择其实是件好事儿也一样。不管怎样，评说者至少应该在了解的基础上再进行评论，才显得“专业”，没有品味的找茬型选手实在不值得恭维。

作为MVC范例集锦，我将MVC发布之后业界的应用开源项目做个简单的整理，Anytao不打算对任何项目发表个人观点，因为有些项目未经本人了解，所以此处仅是one by one式的陈列，期望对学习者有些帮助而已。

• NerdDinner

NerdDinner随着ScottGu、Phli几位大牛为作品《Professional ASP.NET MVC 1.0》谱写的辅助系统，同时通过一个在线系统http://www.nerddinner.com/以生动的实例来展现MVC技术，NerdDinner示例贯穿全书，尤其是第一章的Walkthrough可以让我们对MVC有个初次了解。

• Contact Management

该范例是asp.net/mvc的讲解实例，因为它太简单以至于没有什么好说的，初入MVC的同学可以关注一下，安装step by step的方式构建自己的Contact Management应用。

• MVC Storefront

不知为什么范例程序常常以Store来演示（例如Petshop），可能的原因是Store应用简单而全面，所以MVCStore应用也是这样一个简化示例， 我们可以研究研究。

• Oxite

业界对Oxite有不少批评，Rob Conery是最尖锐的一个，作为“号称”微软MVC范例的Oxite，虽有些细可圈可点，但是离微软官方范例的角度确实还有距离。园子的代震军发表的关于两个MVC示例的思考(MVCStore和Oxite)，对此进行的讨论或许可以给您以思考，从应用角度而言Oxite其实并非一无是处，很多点上还是有不错的运用，例如关于ActionFilter和IoC的应用是值得参考的。

• KIGG

Kigg是Codeplex上开源项目，从项目规模上而言，Kigg属于“大块头”，以MVC为基础架构，同时设计很多技术应用，单元测试也有不错可借鉴的地方。

• Ezsocio

Ezsocio至少可以是个范例，一套基于微软.NET平台的Social Network Software(SNS)系统，会用到许多最新开发技术，如ASP.NET MVC、LINQ、WCF、Unity、JQuery等，虽然还是个半成品，但是作为对于MVC学习和了解角度而言，还是“够用的”。例如以Unity为容器的IoC设计、JQuery在MVC的应用、Validation、Cryptography、Repository模式等，好了不做广告了，那只是个还没有完成的作品。

• sharp-architecture

Sharp-Architecture是MVC和NHibernate应用范例，作为号称“Sharp Architecture”的应用，我想一定可以为我们呈现不一样的设计，对于了解MVC和NHibernate的人或许是个不错的选择。

• fubumvc

fubumvc，可以看作是for us by us MVC，是老赵同志推荐给我的。fubumvc在了解ASP .NET MVC核心架构的基础上，表达了作者“不同意”ASP .NET MVC对于设计的理解，所以几个人凑在一起合谋了fubumvc Framework。这里，有一些关于FubuMVC和ASP .NET MVC的区别。

既然是大观园，可能以后还有补充，谁有更好的分享也可以在留言提供给我，以方便大家“有底放肆”。至于品评和讨论，还是放在以后吧。

更多关注，尽在anytao.net/blog

发布日期：2009.04.23 作者：Anytao
© 2009 Anytao.com ，Anytao原创作品，转贴请注明作者和出处。

提起P/Inoke，我们不可避免的感受到一丝丝的“高深”。一般来说，高深不代表高不可攀，作为.NET平台下于非托管代码交互的基本方式，P/Inoke对大多数Web开发者是个不常光顾的场所，然而互操作问题是或多或少在我们的开发中不期而遇的问题，因为总会在某个偶然我们对托管世界和非托管世界建立一个交集。那么，了解和深入P/Invoke将是你不得不进行起航的拐点，今日我的朋友黄际洲的新书《精通.NET互操作：P/Invoke，C++ Interop和COM Interop》一书提供了一个打开P/Invoke的钥匙，正像本书的定位一样：国内首本全面深入介绍.NET互操作技术的技术书籍。

下面是关于本书的一些简单信息，感兴趣的同志可以拿来读一读，相信对此有很好的收获。首先来看看该书的长相：

• 书号：978-7-115-20434-9
• 作者：黄际洲    崔晓源

本书的内容

本书介绍Windows平台上的托管代码与非托管代码之间进行互操作的各种技术，包括由.NET提供的各种互操作方法、属性以及各种工具的用法及其工作原理。本书包括3部分，平台调用——主要用于解决在托管代码中调用非托管程序设计语言编写的flat API（如Win32 API、C/C++风格的API等）的问题；C++ Interop——技术专门用于解决托管代码与C++编写的非托管代码之间的互操作问题；COM Interop——介绍了使用COM Interop解决在托管代码中调用COM组件，以及在COM中调用托管类型的问题。
本书适合所有在开发过程中需要涉及到托管代码与非托管代码进行交互操作的.NET开发人员阅读使用。不论是开始学习.NET编程的开发人员，还是刚刚接触互操作的资深.NET开发人员，都能从本书中获益。

本书的主要特色

• 国内首本全面深入介绍.NET互操作技术的参考手册
• 系统地介绍针对各种.NET互操作问题的解决方案
• 帮助读者掌握.NET互操作过程中的最佳实践

专家评论

仅则其一二，更多评论请关注相关链接。

托管代码与非托管代码之间的交互是许多程序员在.NET开发平台上不得不面对的任务。《精通.NET互操作性：PInvoke, C++ Interop和COM Interop》这本书深入而透彻地解析了.NET支持的三种与原生代码互操作的技术，作者以自己的经验讲述了原生代码与托管代码之间互操作所涉及到的编程要点，以及背后的一些实现原理。书中提供的实例有助于程序员快速领会并掌握.NET与原生代码互操作技术的用法。我建议在.NET平台上工作的程序员读一读这本书。

——潘爱民（著名技术作家，著写了《COM原理与应用》等多部畅销书，并翻译了多部经典名作，如《深入解析Windows操作系统》（第四版）、《C++ Primer中文版》（第三版）、《COM本质论》、《计算机网络》（第四版）等。他现在微软亚洲研究院从事系统与安全方向的研究工作）

.NET平台是个托管的世界，提供了与以往完全不同的编程模型。毋庸置疑，.NET是当前及未来Windows平台下开发技术的主流。但转到.NET平台并非意味着使用.NET将现有的C/C++/COM代码进行重写。.NET提供的丰富互操作技术使开发人员能够通过这些技术将.NET代码与非托管代码进行集成，以重用现有非托管代码。可惜的是，市场上大部分.NET书籍对互操作技术少有涉足，中文资源尤其缺乏。本书深入且详尽地介绍了如何在托管代码与非托管代码之间进行互操作，涉及到了互操作技术的各个方面，是本非常有价值的参考书，高度推荐！

——金雪根（2002～2005年微软最有价值专家（MVP），CSDN技术论坛.NET版大版主（网名Saucer（思归））。《.NET企业服务框架——应用.NET企业服务开发分布式业务解决方案》的译者之一）

微软发布了.NET Framework框架，这并不意味着要抛弃一切旧的技术，那些长期积累下来的非托管代码编写的东西，经过实践的检验，曾经带来过巨大的价值。将这些原有的代码转换成托管代码是不现实的，如何在托管代码与非托管代码之间进行互操作，继续使用原有的代码，本书给出了详细的解答。本书阐述了托管代码与非托管代码进行交互操作的主要技术，既有理论，又有详细的例子。相信读者通过阅读本书，能够全面掌握.NET互操作性这一技术的。

—— 孟宪会（2002-2008年微软最有价值专家（MVP），微软中文技术论坛版主，CSDN技术论坛.NET及Web开发版大版主（网名 net_lover（孟子E章）），《ASP.NET 2.0应用开发技术》作者，《Eric Meyer谈CSS（卷1）（卷2）》译者）

关于更多

关于本书已经有很多的赞誉，也无需我再次捧场，如果想要了解更多关于 的内容，可以参考以下地址，你会收获更多：

• www.interop123.com
• http://www.cnblogs.com/huangjizhou/archive/2009/04/20/1439837.html

更多的内容、更多的介绍还有更多的推荐，都可以从上获取。

更多关注，尽在anytao.net/blog

发布日期：2009.04.23  作者：Anytao
© 2009 Anytao.com ，Anytao原创作品，转贴请注明作者和出处。

由问题引出

在ASP .NET MVC中，以友好的URL访问资源是MVC吸引眼球的特色之一，但是随之而来对于Authorize问题的处理变得令人令人头痛。例如假设我们有一个获取Book信息的Action，定义在BookController中：

public class BookController : Controller
{
    // Release : code01, 2009/04/22                    
    // Author  : Anytao, http://www.anytao.com
    public ActionResult Index(int id)
    {
        Book model = (new IBookService()).GetBook(id);

        return View(model);
    }
}

那么，我们可以通过http://anytao.net/Book/index/1，来访问id为1的Book（例如该书是《你必须知道的.NET》，哈哈，广告嫌疑）。在没有任何特别处理的情况下，对于该书的访问是“不设防”的。任何用户可以通过http://anytao.net/Book/index/1实现对《你必须知道的.NET》信息的访问。那么访问的资源如果是http://anytao.net/Secret/index/1，显然我的秘密无一例外的对外公开了。

言之此处，我们的问题已经明白无疑，那么应该如何处理呢？我们可以很容易的想到通过以下的方式进行处理：

// Release : code02, 2009/04/22                    
// Author  : Anytao, http://www.anytao.com
public ActionResult Index(int id)
{
    if (new IAuthorizeService().IsBookAuthorized(id, User.Identity.Name))
    {
        Book model = (new IBookService()).GetBook(id);

        return View(model);
    }
    else
    {
        return View("NotValid");
    }
}

显然，我通过IsBookAuthorized对GetBook服务的访问有效性进行控制，通过User的Name在数据库或者其他资源存储进行查找， 然后根据IsBookAuthorized结果进行是否访问的控制，显然不合法的用户将被导航到NotValid页，提示你是非法用户。

这种方式显然是最容易想到的办法，而且也广泛存在于我们实际的应用中，例如NerdDinner范例中也是通过这种方式进行Authorize控制处理的，例如：

[Authorize]
public ActionResult Edit(int id) {

    Dinner dinner = dinnerRepository.GetDinner(id);

    if (!dinner.IsHostedBy(User.Identity.Name))
        return View("InvalidOwner");

    return View(new DinnerFormViewModel(dinner));
}

然而这种方式存在或多或少的问题，例如：

• IsBookAuthorized将分散于不同的Action或者BLL层中，对于统一的Authorized管理带来问题。
• 实际的Authorized执行已经渗透到Action或者Serivce内部，我们更期待在Action调用之前对此已经进行了处理。

思考的瞬间

那么，统一的处理该如何着手实现更优雅的、更统一的Authorize处理呢？显然MVC自带的Authorize特性，为我们提供了可选择的思路：

[Authorize(Users = "Anytao")]
public ActionResult Edit(int id)
{
    return View();
}

Authorize标记通过对于Users或者Roles的定义，来对Edit Action的执行进行“预”Authorize授权，那么登陆用户为Anytao的用户才有权对BookController Edit进行访问，否则将无权访问。显然，这种方式对于满足我们

• 统一Authorize处理
• 在Action调用之前进行授权验证

的目标是统一的。所以，我们可以借助这种方式实现自定义的统一Authorize处理方案。

统一Authorize解决方案

有了指导方针，我们就可以有的放肆了，我们的方案同样是应用ActionFilter实现对Authorize处理，上次的范例是{[一步一步MVC]第四回：使用ActionSelector控制Action的选择}。显然我们可以在OnActionExecuting事件中对Action进行“预”处理，将关于Authorize的验证过程统一在OnActionExecuting中进行，就可以对标记的Action实现调用之前的过滤了，所以我们首先实现一个AuthorizeAttributeBase，例如：

// Release : code03, 2009/04/22                    
// Author  : Anytao, http://www.anytao.com
public abstract class AuthorizeAttributeBase : ActionFilterAttribute
{
    public AuthorizeAttributeBase()
    { 
    }

    public AuthorizeAttributeBase(string key)
    {
        Key = key;
    }

    public override void OnActionExecuting(ActionExecutingContext filterContext)
    {

        // Authorize handler 
    }

    public string Key { get; set; }

    protected abstract bool IsAuthorized(int id);
}

而具体的验证则在具体实现类中，例如我们对Book的验证：

// Release : code04, 2009/04/22                    
// Author  : Anytao, http://www.anytao.com
public class BookAuthorizeAttribute : AuthorizeAttributeBase
{
    protected override bool IsAuthorized(int id)
    {
        return (new IAuthorizeService()).IsBookAuthorized(id);
    }
}

对于验证的处理必须解决两方面的问题：

• 在AuthorizeAttributeBase中获取待过滤Action中的参数（Index(int id)），一般而言我们需要对id进行验证，那么传入id的值该如何处理。
• 在AuthorizeAttributeBase对于非法用户的处理，一般而言就是导航到NotValid页面。

在OnActionExecuting中获取Action参数

我们采用的方法是通过filterContext的ActionParameters来获取参数值，通过参数的Key来获取其值，例如：

if (filterContext.ActionParameters.ContainsKey(key))
{
    value = int.Parse(filterContext.ActionParameters[key].ToString());
}

在OnActionExecuting中导航到不同的View

这也是一个简单的处理，我们只要指定好filterContext的Result为指定的ViewResult即可实现我们的目标：

filterContext.Result = new ViewResult{
    ViewName = "NotValid"
};

解决了上述问题，就基本实现了对Authorize进行统一处理的目标，至于具体的Authorize逻辑，不同的业务可以在不同的业务层进行封装。例如对于Book资源的处理可以统一在IBookService中，对于User资源的处理可以统一在IUserService中（不过显然我们已经有了MVC自带的Authorize，不必重复），对于其他的资源也相应的处理在不同的业务层中。

下面是AuthorizeAttributeBase和BookAuthorizeAttribute的完整代码：

// Release : code03, 2009/04/22                    
// Author  : Anytao, http://www.anytao.com
public abstract class AuthorizeAttributeBase : ActionFilterAttribute
{
    public AuthorizeAttributeBase()
    { 
    }

    public AuthorizeAttributeBase(string key)
    {
        Key = key;
    }

    public override void OnActionExecuting(ActionExecutingContext filterContext)
    {
        string key = string.IsNullOrEmpty(Key) ? "id" : Key;

        int id;

        if (filterContext.ActionParameters.ContainsKey(key))
        {
            if (!int.TryParse(filterContext.ActionParameters[key].ToString(), out id))
            {
                id = 0;
            }
        }
        else
        {
            id = 0;
        }

        if (id > 0)
        {
            if (IsAuthorized(id))
            {
                base.OnActionExecuting(filterContext);
            }
            else
            {
                filterContext.Result = new ViewResult{
                    ViewName = "NotValid"
                };


            }
        }
        else
        {
            filterContext.Result = new ViewResult{
                    ViewName = "NotValid"
                };
        }
    }

    public string Key { get; set; }

    protected abstract bool IsAuthorized(int id);
}

接下来就是如何应用了。

在Controller中应用统一Authorize处理

下面是我们的应用，还是对于http://anytao.net/Book/index/1的访问，我们可以像下面这样应用：

// Release : code05, 2009/04/22                    
// Author  : Anytao, http://www.anytao.com
[BookAuthorize(Key="id")]
public ActionResult Index(int id)
{
    Book model = (new IBookService()).GetBook(id);

    return View(model);
}

对比前后的两种方案，我想孰优孰劣显而易见。BookAuthorize显然以更优雅的方式实现了对于Authorize这回事儿的处理，也基本达到了原来的目标。我们的验证逻辑没有散落在系统四处，如何同时需要对Book的Index进行多个逻辑的验证，我们的方式也变得很简单，例如：

// Release : code05, 2009/04/22                    
// Author  : Anytao, http://www.anytao.com
[BookAuthorize(Key="id"), TaskAuthorize(Key="id")]
public ActionResult Index(int id)
{
    Book model = (new IBookService()).GetBook(id);

    return View(model);
}

不过，我们需要对id的复用进行一点思考，不过那已经是另外一回儿事儿了。对本文而言，我已经达到了目标。当然，这也许不是最好的方案，所以我期待您的更好方案，因为技术需要切磋和共享。

又是一个小技巧，希望给你帮助。

代码下载[anytao_mvc_actionauthorize]，更多关注，尽在anytao.net/blog

发布日期：2009.04.21  作者：Anytao
© 2009 Anytao.com ，Anytao原创作品，转贴请注明作者和出处。

ActionFilter一定是MVC控制中对于Action控制中最值得研究的玩意，在项目实际中我们不可避免的使用例如：

• HandleError
• Authorized
• OutputCache

在本文中，我们应用Action Selector方式进行Action的选择，想要阐述清楚这个问题，我们从实际的问题出发来关注。

实际的问题，从和老赵的对话了解

我们有个业务室这样的：系统有不同的角色，例如Admin、Client、Agent。假设有个功能叫Book/List，那么就对应了一个List这样的View和action为List这样的BookController，现在，我们的情况是对于不同的角色，所对应的List是不同的。Admin看到的Book/List和Client看到的Book/List是不同的，那么通过Url：http://anytao.com/Book/List/123，不同的角色如何处理，差不多就这样，是否清楚。

我：那么对于同一Action如何更好的return到不同的view？

老赵：具体问题是什么呢？

我： 我现在能想到的是在Action中根据角色Return到不同的View，简单的办法就是在List Action根据角色Return到不同的View。问题是，还有什么更好的办法。

老赵：准备n各action，分别加上自定的ActionSelector，不要用一个Action，不用一个Action然后在里面if。

[OnlyInRole("admin")] 
[ActionName("List")]
ListForAdmin() 
{
}

[OnlyInRole("user")] 
[ActionName("List")]
ListForUser() 
{
}

OnlyInRole需要自己写，不过就几行话

我： 哈哈，差不多了，谢啦。

根据老赵的指导，我对此思路进行了必要的探讨，感受果然不同凡响，很好很暴力。

解决方案

为了实现对于Action进行Selector的具体实现，我选择对ActionNameSelectorAttribute 进行扩展，参考ActionName的实现方式，对于按照RoleType进行过滤的需求显然有很好的借鉴价值，以ActionNameAttribute为例，其具体实现为：

[AttributeUsage(AttributeTargets.Method, AllowMultiple = false, Inherited = true)]
public sealed class ActionNameAttribute : ActionNameSelectorAttribute {

    public ActionNameAttribute(string name) {
        if (String.IsNullOrEmpty(name)) {
            throw new ArgumentException(MvcResources.Common_NullOrEmpty, "name");
        }

        Name = name;
    }

    public string Name {
        get;
        private set;
    }

    public override bool IsValidName(ControllerContext controllerContext, string actionName, MethodInfo methodInfo) {
        return String.Equals(actionName, Name, StringComparison.OrdinalIgnoreCase);
    }

}

再来了解ActionNameSelectorAttribute抽象类的定义，其主要提供了对Action进行Select时的IsValidName判断约定，例如ActionNameSelectorAttribute的定义：

[AttributeUsage(AttributeTargets.Method, AllowMultiple = false, Inherited = true)]
public abstract class ActionNameSelectorAttribute : Attribute {
    public abstract bool IsValidName(ControllerContext controllerContext, string actionName, MethodInfo methodInfo);
}

所以，对ActionNameSelecterAttribute进行扩展变得异常简单，下面是一个最简单的实现，肯定让我们耳目一新：

// Release : code01, 2009/04/17                    
// Author  : Anytao, http://www.anytao.com
public class ActionInRoleAttribute : ActionNameSelectorAttribute
{
    public ActionInRoleAttribute(RoleType role)
    {
        this.role = role;
    }

    public override bool IsValidName(ControllerContext controllerContext, string actionName, System.Reflection.MethodInfo methodInfo)
    {
        if (controllerContext.HttpContext.User.IsInRole(role.ToString()))
        {
            return true;
        }
        else
        {
            return false;
        }
    }

    private RoleType role;
}

我们的逻辑其实很简单，借助于IPrincipal的IsInRole方法，可以很简单的根据role的定义进行IsValidName过滤，例如我们的应该可以就是：

// Release : code02, 2009/04/17                    
// Author  : Anytao, http://www.anytao.com
[AcceptVerbs(HttpVerbs.Get)]
[ActionName("List")]
[ActionInRole(RoleType.Client)]
public ActionResult ClientList(int id)
{
    return View(
        "ClientBookList",
        new Book
        {
            ID = id,
            Name = string.Empty
        });
}

// Release : code03, 2009/04/17                    
// Author  : Anytao, http://www.anytao.com
[AcceptVerbs(HttpVerbs.Get)]
[ActionName("List")]
[ActionInRole(RoleType.Admin)]
public ActionResult AdminList(int id)
{
    return View(
        "AdminBookList",
        new Book
        {
            ID = id,
            Name = string.Empty
        });
}

调用List Action时，根据登陆用户的角色来决定具体执行的Action（ClientList或者AdminList），并由不同的Action导航到不同的View（ClientBookList或者AdminBookList），而对于不同Action访问的URL都是一样的（http://anytao.com/Book/List/123），同时避免了在服务层对角色的判断，某种程度上按照RoleType对于Controller层进行了“注入”，使得Controller层的逻辑不在关心Action过滤的问题。

不过，在应用上还有一些值得注意的问题：

• 使用非泛型ActionLink方法调用应用ActionInRole 的Action

一般而言，我们提倡应用强类型ModelData在View层进行操作，那么泛型方法ActionLink值得推荐，

<p>
    <%= Html.ActionLink<BookController>(c => c.List(Model.ID), "List") %>
</p>

然而，应用被ActionInRole标记的，同时被ActionName重命名的Action，将不被识别，我们只好以非泛型方式实现对于一名多用的Action来调用：

<p>
    <%= Html.ActionLink("List", "List", new { id=Model.ID }) %>
</p>

• 在return View中通过制定ViewName进行返回，来选择适合的View，例如

return View(
    "AdminBookList",
    new Book
    {
        ID = id,
        Name = string.Empty
    });

因为默认情况下，MVC引擎是以ActionName进行返回的，在我们的应用中必须以这种方式进行。

结论

本文着重于应用，而没有特别对什么是ActionFilter进行探讨，我们在合适的时间再次与MVC握手，对此进行进一步进行讨论。

更多关注，尽在anytao.net/blog

特别鸣谢：

• 老赵，该方案是老赵MSN提议的解决方案，经实际测试果然名不虚传，故做此文以济之。

《你必须知道的.NET》网站 | Anytao技术博客 

发布日期：2009.04.12 作者：Anytao
© 2009 Anytao.com ，Anytao原创作品，转贴请注明作者和出处。

对集合元素进行排序是经常发生的事情，事实上大部分的集合类型都默认实现了Sort方法，进行其元素的排序操作。例如List<T>集合的Sort方法有：

public void Sort();
public void Sort(Comparison<T> comparison);
public void Sort(IComparer<T> comparer);
public void Sort(int index, int count, IComparer<T> comparer);

在排序使用上，四个Sort是大同小异，唯一不同的是大部分情况下，排序的要求决定了我们不能完全满足于默认排序的情况，因为Framework根本不清楚“你”排序的目的，例如：

BookStore bs = new BookStore
{
    Books = new List<Book> { 
        new Book{ID = 1, Name="你必须知道的.NET", Price=69, PublishDate=DateTime.Parse("2008-3-30")},
        new Book{ID = 2, Name="Silverlight完美征程", Price=75, PublishDate=DateTime.Parse("2009-4-30")},
        new Book{ID =3, Name="博客园精华集", Price=72, PublishDate=DateTime.Parse("2009-5-3")}    
    }
};

实现自定义的排序算法

如果需要对书店的书目进行排序，那么在我们的小示例中至少可以按照书名、书价和出版日期进行排序，因此.NET Framework在设计上为Sort提供了很好的扩展，通常情况下我们需要实现自定义的comparison和comparer，例如：

            // Release : code01, 2009/04/12                    
            // Author  : Anytao, http://www.anytao.com 
            // List    : Protram.cs

            //02 Sort by custom comparison
            bs.Books.Sort((a, b) => { return a.Price.CompareTo(b.Price); });

            foreach (var item in bs.Books)
            {
                Console.WriteLine(string.Format("{0}:{1}, {2}", item.Name, item.Price, item.PublishDate.ToString()));
            }

你看利用Lambda表达式实现一个Custom Comparison是何其简单：

bs.Books.Sort((a, b) => { return a.Price.CompareTo(b.Price); });

输出的结果为：

如果我们实现以出版日期进行排序的Custom Comparison，应该是这样：

bs.Books.Sort((a, b) => { return a.PublishDate.CompareTo(b.PublishDate); });

排序的结果如我所愿：

利用Lamdba表达式实现的Comparison变得非常简单，优雅有度，我们回归复杂将Lamdba表达式解析为匿名方法（Anonymous Method）：

// Release : code01, 2009/04/12                    
// Author  : Anytao, http://www.anytao.com 
// List    : Protram.cs

//03 Sort by custom comparison: Anonymous Method
bs.Books.Sort(delegate(Book a, Book b)
{
    return a.Price.CompareTo(b.Price);
});

如果你对匿名方法还心存芥蒂，那么我们回归Custom Comparison的最本源实现：

// Release : code01, 2009/04/12                    
// Author  : Anytao, http://www.anytao.com 
// List    : BookComparison.cs

public class BookComparison : IComparer<Book>
{
    public int Compare(Book x, Book y)
    {
        return x.Price.CompareTo(y.Price);
    }
}

利用BookComparison 进行比较，

//04 Sort by custom comparison: BookComparison
bs.Books.Sort(new BookComparison().Compare);

输出的结果和bs.Books.Sort((a, b) => { return a.Price.CompareTo(b.Price); });一样，可谓皆大欢喜。

以自定义方式可以实现的更多的控制，例如我们重构BookComparison：

// Release : code01, 2009/04/12                    
// Author  : Anytao, http://www.anytao.com 
// List    : BookComparison.cs

public class BookComparison : IComparer<Book>
{
    private ComparisonType type;

    public BookComparison(ComparisonType type)
    {
        this.type = type;
    }

    public int Compare(Book x, Book y)
    {
        switch (this.type)
        {
            case ComparisonType.Price:
                return x.Price.CompareTo(y.Price);
                break;
            case ComparisonType.PublishDate:
                return x.PublishDate.CompareTo(y.PublishDate);
                break;
            default:
                break;
        }

        return 0;
    }
}

添加一个ComparisonType结构，在BookComparson初始化时决定Comparison的方式：

//04 Sort by custom comparison: BookComparison
bs.Books.Sort(new BookComparison(ComparisonType.PublishDate).Compare);

结论

自定义Comparison为实现更好的Sort控制，提供了很好的扩展机制。在我们的实际应用中，对于例如BookStore这样的具体应用而言，我更推荐以LINQ的OrderBy来实现，例如：

//05 Sort by Linq
var list = from c in bs.Books
           orderby c.PublishDate ascending
           select c;

foreach (var item in list)
{
    Console.WriteLine(string.Format("{0}:{1}, {2}", item.Name, item.Price, item.PublishDate.ToString()));
}

orderby子句可以选择任意的排序条件，同时ascending或者descending控制升序和降序。

何去何从，看官自评。

anytao | © 2009 Anytao.com

2009/04/12 | http://anytao.cnblogs.com/ | http://anytao.net/blog/post/2009/04/12/anytao_devstory_04_customcomparisonhtml.aspx

本文以“现状”提供且没有任何担保，同时也没有授予任何权利。 | This posting is provided &quotAS IS" with no warranties, and confers no rights.

本文版权归作者所有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。

[玩转Silverlight]第五回：应用篇，在Silverlight中使用Virutal Earth地图服务

发布日期：2009.03.29 作者：Anytao
© 2009 Anytao.com ，Anytao原创作品，转贴请注明作者和出处。

畅游地球是个美好的愿望，随着地图服务的日益完善，我们足不出户畅游全球已变得简单异常。事实上，Google Earth和Virutal Earth已经成为Web服务中的必选目标，为自己的网站加入Earth或者Map地图服务是件非常酷的事情，那么在我们的Silverlight应用中使用地图服务是否能够得心应手呢？

答案是肯定的，我们操作Earth服务只需执行简单的服务调用，就可完成坐地日行八万里的壮举了，而这一切是由VIEWs组件封装了Javascript脚本来完成的，通过对Virtual Earth Service的调用，在Silverlight中使用托管代码完成简单消费。

下面我们来看看这一过程是如何实现的？

必要的准备

必要的准备其实很简单，主要包括：

• VIEWS.dll，封装了对脚本的处理逻辑类VEMap。
• ScriptInterop.dll，包含VEMap的基类JSObject。
• views.js，调用Virtual Earth服务。

对此，我们无需多做解释，在代码中自会由明白的演示。

实现的过程

• 创建Silverlight项目和Web项目（例如Anytao.SLight.MapAccess和Anytao.SLight.MapAccess.Web），在Silverlight项目中Add Reference VIEW和ScriptInterop程序集，在Web项目中引入views脚本。
• 在Silverlight宿主页面引入views.js脚本和virtualearth服务脚本

<script type="text/javascript" src="http://dev.virtualearth.net/mapcontrol/mapcontrol.ashx?v=6.1"></script>    
<script type="text/javascript" src="views.js"></script>

• 为Virtual Earth创建容器

<div id="myMap" style="position:absolute; width:640px; height:480px; top:105px;"></div>

• 在Silverlight中添加调用布局

<Grid x:Name="LayoutRoot" Background="Azure">
    <StackPanel Orientation="Vertical" >
        <StackPanel Orientation="Horizontal" HorizontalAlignment="Center" VerticalAlignment="Top">
            <TextBox x:Name="tbPlace" Width="200" Height="30" Text="Beijing" Margin="5" />
            <Button x:Name="btnFind" Width="100" Content="Find" Height="30" Click="btnFind_Click" />
        </StackPanel> 
        <HyperlinkButton x:Name="codeload" HorizontalAlignment="Center" Content="Code Download" Margin="10" Click="codeload_Click" />
        <TextBlock HorizontalAlignment="Center" Text="2009, Anytao.com" />
    </StackPanel>
</Grid>

• 实现具体的调用逻辑

// Release : code01, 2009/03/03                    
// Author  : Anytao, http://www.anytao.com 
// List    : Page.xaml.cs
public partial class Page : UserControl
{
    private VEMap map;
    private VEShapeLayer layer;

    public Page()
    {
        InitializeComponent();

        Loaded += new RoutedEventHandler(Page_Loaded);
        codeload.Content = "Download: " + App.Current.GetType().Namespace;
    }

    void Page_Loaded(object sender, RoutedEventArgs e)
    {
        //Create from container
        map = new VEMap("myMap");
        HtmlPage.RegisterScriptableObject("SLMAP", map);

        //Location in Beijing
        VELatLong point = new VELatLong(39.92, 116.46);
        //Loading the earth
        map.LoadMap(point, 11);
    }

    private void btnFind_Click(object sender, RoutedEventArgs e)
    {
        //Find a location
        map.Find(string.Empty, tbPlace.Text);
    }
}

• OK，大功告成，我们欣赏并搜索自己的地方了，默认情况下我们首先会看得伟大首都的缩影。

当然，还有更多的控制，我们没有演示，大家可以了解了解VEMap提供的服务和接口，相信你能获取更多超酷的地图探索体验。

示例演示

参考文献

• http://www.codeplex.com/views

温故知新

• 第一回：基础篇，品尝与HttpHandler通信
• 第二回：应用篇，Silverlight本地化
• 第三回：基础篇，在Silverlight中使用基于WCF的REST服务（上）
• 第四回：基础篇，在Silverlight中使用基于WCF的REST服务（下）

[你必须知道的.NET]第二十八回：说说Name这回事儿

发布日期：2009.3.18 作者：Anytao
© 2009 Anytao.com ，原创作品，转贴请注明作者和出处。

1 缘起

老赵在谈表达式树的缓存（2）：由表达式树生成字符串中提到，在描述Type信息时讨论FullName或者AssemblyQualifiedName提供完整的Type信息，虽是小话题，但却是值得有聊的话题。在.NET中反应一个Type名称信息的有以下三个属性，分别是：

• Name，获取当前成员的名称。
• FullName，获取Type 的完全限定名，包括Type的命名空间，但不包括程序集。
• AssemblyQualifiedName，获取Type的程序集限定名，其中包括从中加载Type 的程序集的名称。事实上，AssemblyQualifiedName被定义为只读abstract属性，具体的实现由其派生类来实现，例如TypeBuilder，我们可以根据其具体实现类型对此有个大致的了解。

此处的定义毋庸置疑是官方的（MSDN），俗话说，事实是检验真理的唯一标准，那么这三个相近的概念，究竟代表了怎样的不同，我们回到事实近看分晓。

2 畅聊Name

2.1 由简单的开始

由简单开始，我们不妨看看object的三个不同Name返回的事实真相：

static void Main(string[] args)
{
    Type t1 = typeof(object);
    Console.WriteLine(t1.Name);
    Console.WriteLine(t1.FullName);
    Console.WriteLine(t1.AssemblyQualifiedName);
}

执行结果呢？

诚如MSDN所说，Name返回了简单的类型名称，FullName包含命名空间，而AssemblyQualifiedName则包含程序集全名称。而对于非强名称程序集，其AssemblyQualifiedName依然返回，相关的程序集信息，例如：

Console.WriteLine(t3.AssemblyQualifiedName);

Anytao.Learning.ExpressionTree.One, Anytao.Learning.ExpressionTree, Version=1.0.
0.0, Culture=neutral, PublicKeyToken=null

2.2 向复杂过度

如果我们只把目光停留在简单类型，那么这三个家伙也不值得花点小时间来注意了，除了简单，还得复杂。所以，我饶尤其是的把Expression拿来抓丁了：

static void Main(string[] args)
{
    Type t2 = typeof(Expression<Func<int, int>>);
    Console.WriteLine(t2.Name);
    Console.WriteLine(t2.FullName);
    Console.WriteLine(t2.AssemblyQualifiedName);
}

执行的结果呢？

显然，对于答案，引起我们关注的是在Expression<Func<int, int>>中，其FullName的Func<int, int>类型，以及int类型均获取到其AssemblyQualifiedName，而不是FulName。这留给我们一个大大的疑问，对其原因进行一点点深究，我们就可以有这样的思考，Func<T>以及int分别存在于System.Core和mscorlib程序集，对于我们本身程序集而言，完全有可能在其他引用程序集中引入一个FullName相同的Assembly，所以为唯一限定起见，以AssemblyQualifiedName标示Func<T>和int是完全正确的。

同意的问题，存在于List<T>等其他类型。任何可替换类型参数的实际类型，都可能由不同程序集的加载而变得不够“唯一”，所以AssemblyQualifiedName来限定List<T>的FullName是明智的。

2.3 顺便看看Type.ToString()

Type类型还有一个ToString()，用于返回Type的Name，那么这个Name究竟是这三个中的哪一个呢？如果看了答案，你肯定又一次崩溃：

static void Main(string[] args)
{
    Type t1 = typeof(object);
    Type t2 = typeof(Expression<Func<int, int>>);
    Type t3 = typeof(One);
    Type t4 = typeof(List<int>);
    Console.WriteLine(t1.ToString());
    Console.WriteLine(t2.ToString());
    Console.WriteLine(t3.ToString());
    Console.WriteLine(t4.ToString());
}

我们看看此时的结果：

虽然很无语，Type.ToString()事实上并未返回Name、FullName或者AssemblyQualifiedName，而是不完全的FullName，具体就不做过多陈述了，我们可以由结果看得很明白。

3 回到问题

显然，FullName在一个程序集中是唯一限定的，包含了所在的命名空间，而AssemblyQualifiedName则更包含其程序集名称，对于复杂类型的例如List<T>这样的类型，即便是FullName也将以AssemblyQualifiedName显示其类型参数，所以对于老赵的方案FullName是完全可以胜任为不同Type实现唯一key值的需求。

你认为呢？

温故知新

[开篇有益]
[第一回：恩怨情仇：is和as]
[第二回：对抽象编程：接口和抽象类]
[第三回：历史纠葛：特性和属性]
[第四回：后来居上：class和struct]
[第五回：深入浅出关键字---把new说透]
[第六回：深入浅出关键字---base和this]
[第七回：品味类型---从通用类型系统开始]
[第八回：品味类型---值类型与引用类型（上）－内存有理]
[第九回：品味类型---值类型与引用类型（中）－规则无边]
[第十回：品味类型---值类型与引用类型（下）－应用征途]
[第十一回：参数之惑---传递的艺术（上）]
[第十二回：参数之惑---传递的艺术（下）]
[第十三回：从Hello, world开始认识IL]
[第十四回：认识IL代码---从开始到现在]
[第十五回：继承本质论]
[第十六回：深入浅出关键字---using全接触]
[第十七回：貌合神离：覆写和重载]
[第十八回：对象创建始末（上）]
[第十九回：对象创建始末（下）]
[第二十回：学习方法论]
[第二十一回：认识全面的null]
[第二十二回：字符串驻留（上）---带着问题思考]
[第二十三回：品味细节，深入.NET的类型构造器]
[第二十四回：认识元数据和IL（上）]
[第二十五回：认识元数据和IL（中）]
[第二十七回：interface到底继承于object吗？]

[你必须知道的.NET]第二十七回：interface到底继承于object吗？

发布日期：2009.03.05 作者：Anytao
© 2009 Anytao.com ，Anytao原创作品，转贴请注明作者和出处。

说在，开篇之前

在.NET世界里，我们常常听到的一句话莫过于“System.Object是一切类型的根，是所有类型的父类”，以至于我在《你必须知道的.NET》8.1节 以“万物归宗：System.Object”这样的title为System.Object授予至高荣誉。所以，基于这样的观点就有了下面这句“接口是否也继承于System.Object？”，事实上这正是今天在技术群里小小讨论的一个插曲。                                                                                        www.anytao.com

1 缘起

在.NET世界里，我们常常听到的一句话莫过于“System.Object是一切类型的根，是所有类型的父类”，以至于我在《你必须知道的.NET》8.1节 以“万物归宗：System.Object”这样的title为System.Object授予至高荣誉。所以，基于这样的观点就有了下面这句“接口是否也继承于System.Object？”，事实上这正是今天在技术群里小小讨论的一个插曲。

持“interface也继承于object”，是基于以下的两个观点推断的：

观点一：

接口本质上也是一个class，因为接口类型编译之后在IL中被标识为.class，既然是类那么不可避免的最终继承于System.Object。

观点二：

假如有如下的接口和实现接口的类型：

// Release : code01, 2009/03/04                    
// Author  : Anytao, http://www.anytao.com
// List    : IObjectable.cs
public interface IObjectable
{
}

// Release : code02, 2009/03/04                    
// Author  : Anytao, http://www.anytao.com
// List    : MyObject.cs
public class MyObject : IObjectable
{
}

那么，对于IObjectable对象而言，下面的调用是可行的：

// Release : code03, 2009/03/04                    
// Author  : Anytao, http://www.anytao.com
// List    : Program.cs
class Program
{
    static void Main(string[] args)
    {
        IObjectable obj = new MyObject();

        //Call Object instance methods
        obj.ToString();
        //Call Object static methods
        IObjectable.Equals(null, null);
    }
}

显然，IObjectable类型变量obj可以访问存在于System.Object中的实例方法ToString()和虚方法Equals，当然其他的几个公共服务也不例外：GetType()、Equals()、GetHashcode()、ReferenceEquals()，也可以由此推断interface可访问Object方法的蛛丝马迹。

不可否认，以上观点的部分推理是完全正确的，但是却遗憾的导致了错误的答案，所以在本文中我将明确的找出：interface不继承于object的原因和原理。关于接口本质话题的深度讨论，请参考《你必须知道的.NET》1.5 “玩转接口”和7.4 “面向抽象编程：接口和抽象类”的详细分析。

2 从面向对象寻找答案

为了找出接口继承的原因，我想从接口存在的意义入手是最能够说明问题的办法？接口，就像面向对象设计中的精灵，为OO思想注入了灵魂和活力，接口突破了继承在纵向上的扩展方向，在横向给予对象以更灵活的支持机制。

接口，封装了对于行为的抽象，定义了实现者必须遵守的契约。例如，实现了System.ICloneable接口的类型被赋予了“可以被拷贝”这样的契约，实现了System.Collections.IEnumerable接口的类型被赋予了“可以被枚举”这样的契约，不同的接口定义了不同的契约，就像不同的法律约束了不同的行为。那么接口应该赋予的契约至少在层次上保持相对的单纯和统一，如果为所有接口都无一例外的赋予GetType()、Equals()、GetHashcode()、ReferenceEquals()还有ToString()这样的契约，未免使得接口的纯洁和统一变得无从谈起，例如强迫任何实现了System.ICloneable接口的类型同时遵守其他的约定是对ICloneable本身的侮辱。

从接口单一原则延伸思考，一个包含杂七杂八的接口定义显然不是interface应该具有的纯正血统，对于深谙面向对象为何物的.NET设计者而言，这是不言而喻的问题。所以，我们从接口本身的职责和意义出发，决定interface不从System.Object继承是完全正确的。

3 在IL探求究竟

再次应用强大的IL武器来探求事实的真相，我们以Reflector打开所有的.NET既有接口，例如IList、IEmumerable、ICollection，都会有个共同的发现那就是你找不到extends System.Object这样的标识：

.class public interface abstract auto ansi ICloneable
{
    .custom instance void System.Runtime.InteropServices.ComVisibleAttribute::.ctor(bool) = { bool(true) }
    .method public hidebysig newslot abstract virtual instance object Clone() cil managed
    {
    }
}

自定义类型也是如此，我们看看IObjectable的IL反编译定义：

.class public interface abstract auto ansi IObjectable
{
}

而以extends标识继承关系是IL代码告诉我们真相的最佳证明。

System.Object真是“万物归宗”吗？

让我们再次回眸一笑，把Object进行一番把玩，难道一切类型都得继承自Object吗？其实不然。以ILASM.exe进行IL代码编译时，有一个参数选项NOAUTOINHERIT，正如其解释所描述的那样：

/NOAUTOINHERIT  Disable inheriting from System.Object by default

显然NoAutoInherit选项提供了为.NET类型“去掉帽子”的作用，简单言之就是，在未指定基类时，禁止类型自动从Object继承。

我们可以玩儿一个翻来覆去的IL游戏，将我们本文开始的Anytao.Insidenet.InterfaceInside.exe控制台程序以ILDASM.exe工具Dump为IL代码My.il，例如MyObject被反编译为：

.class public auto ansi beforefieldinit Anytao.Insidenet.InterfaceInside.MyObject
       extends [mscorlib]System.Object
       implements Anytao.Insidenet.InterfaceInside.IObjectable
{
  .method public hidebysig specialname rtspecialname 
          instance void  .ctor() cil managed
  {
    // Code size       7 (0x7)
    .maxstack  8
    IL_0000:  ldarg.0
    IL_0001:  call       instance void [mscorlib]System.Object::.ctor()
    IL_0006:  ret
  } // end of method MyObject::.ctor

} // end of class Anytao.Insidenet.InterfaceInside.MyObject

我们可以选择删除其中所有extends继承的代码，再以ILASM.exe对其进行noautoinherit编译，并生成

ilasm /exe /output:noobject.exe /noautoinherit my.il

新生成的noobject.exe程序将没有从object继承，某种程度上打破了“万物归宗”的创奇，MyObject就像一个无根之木，飘摇在我机器的某个深处。

4 结论

interface不从object继承，那么足下高见呢？文章虽短，取一瓢饮之，畅也。

那么，我们该如何回答本文开始对此质疑的两种观点呢？

回答观点一：

接口本质上还是一个类，但是一个特殊的类，它的特殊性表现在诸多的方面，例如所有的方法和属性都是抽象的、支持多继承等等，既然特殊那就特殊到底，不继承于任何的父类也是其中之一吧。

虽然这种解释未免牵强，但是如前文所述回到接口本源的角度而言，却是最好的解释。

回答观点二：

.NET一切类型都隐式继承于System.Object，那么对于实现了任何接口的类型而言，例如：

// Release : code02, 2009/03/04                    
// Author  : Anytao, http://www.anytao.com
// List    : MyObject.cs
public class MyObject : IObjectable
{
}

其在本质上相当于：

// Release : code02, 2009/03/04                    
// Author  : Anytao, http://www.anytao.com
// List    : MyObject.cs
public class MyObject : Object, IObjectable
{
}

所以对于MyObject实例obj而言，obj.ToString()实质是MyObject类继承于object，而不代表接口IObjectable也继承于object。那么IObjectable.Equals()则是编译器做了手脚，将IObjectable.Equals()翻译为Object.Equals()所致（来自脑袋高论，表示热烈感谢）。事实上，对于接口声明类型的方法调用，在实现机制上完全不同于一般的直接方法调用和虚方法分派机制，我们将在后续篇幅中详细讨论这一更重要的话题。

好了，interface，想说爱你不容易，可能我们还会再次相遇，也敬请朋友们继续关注：你必须知道的.NET。

友情支持：脑袋、飞林沙 、博客园北京俱乐部

• 《你必须知道的.NET》1.5 “玩转接口” 
• 《你必须知道的.NET》7.4 “面向抽象编程：接口和抽象类”
• http://www.cnblogs.com/allenlooplee/archive/2007/01/22/627386.html

温故知新

[开篇有益]
[第一回：恩怨情仇：is和as]
[第二回：对抽象编程：接口和抽象类]
[第三回：历史纠葛：特性和属性]
[第四回：后来居上：class和struct]
[第五回：深入浅出关键字---把new说透]
[第六回：深入浅出关键字---base和this]
[第七回：品味类型---从通用类型系统开始]
[第八回：品味类型---值类型与引用类型（上）－内存有理]
[第九回：品味类型---值类型与引用类型（中）－规则无边]
[第十回：品味类型---值类型与引用类型（下）－应用征途]
[第十一回：参数之惑---传递的艺术（上）]
[第十二回：参数之惑---传递的艺术（下）]
[第十三回：从Hello, world开始认识IL]
[第十四回：认识IL代码---从开始到现在]
[第十五回：继承本质论]
[第十六回：深入浅出关键字---using全接触]
[第十七回：貌合神离：覆写和重载]
[第十八回：对象创建始末（上）]
[第十九回：对象创建始末（下）]
[第二十回：学习方法论]
[第二十一回：认识全面的null]
[第二十二回：字符串驻留（上）---带着问题思考]
[第二十三回：品味细节，深入.NET的类型构造器]
[第二十四回：认识元数据和IL（上）]
[第二十五回：认识元数据和IL（中）]
[第二十六回：认识元数据和IL（下）]