多态（Polymorphism）一词源于生物学，顾名思义就是指多种形态。在面向对象世界里，多态与继承和封装一起构成了三大核心概念。

在.NET中，多态通常意味着子类对于父类一种衍变。子类继承自父类，拥有父类所定义的一切（public或protected）成员。但同时，它又可以修改（重写或复写）这些成员，使其实现与父类以及其他子类完全不同。我们可以说，继承体现了类的多态性。

大家应该很熟悉Duck的例子了吧？

public abstract class Duck
{
    public abstract void Quack();
}

public class MallardDuck : Duck
{
    public override void Quack()
    {
        Console.WriteLine("Quack, quack, quack...");
    }
}

public class RubberDuck : Duck
{
    public override void Quack()
    {
        Console.WriteLine("Squeak, squeak, squeak...");
    }
}

public class Program
{
    public static void Main()
    {
        Duck duck = new MallardDuck();
        duck.Quack();
        duck = new RubberDuck();
        duck.Quack();
        Console.ReadLine();
    }
}

MallardDuck和RubberDuck虽然都继承自抽象类Duck，同样拥有Quack()方法，但它们却有不同的实现，产生不同的结果。在声明Duck类型时，既可以实例化为Mallard，也可以实例化为RubberDuck，或者是其他继承自Duck的类，在运行时，将自动调用各个子类的实现。

多态的这些特性使依赖注入和面向抽象编程成为可能，其重要性不言而喻。

不一样的多态

然而，既然多态是指同一类事物之间的不同形态，那么我们为什么要把对于多态的理解局限于类的继承关系呢？在.NET中是否还存在着非继承关系的多态性呢？

泛型体现了参数的多态性

类型参数在泛型中通常解释为占位符，而我更愿意将其理解为对参数的一种抽象。以最常见的List<T>为例，List<string>和List<int>在语法上完全相同，仅仅是类型参数有所不同，然而它们却是两个完全不同的类。也就是说，是类型参数的不同，导致了不同的类的形态。

public class MyList<T>
{
    private T[] items;
    private int size;
    public void Add(T item)
    {
        if (size == items.Length)
        {
            // modify capacity
        }
        items[size++] = item;
    }
}

如果我们使用MyList<string>，在内部就会声明一个字符串数组，Add方法的参数也必须为string。如果使用MyList<int>，在内部就会声明一个int数组，Add方法的参数也必须为int。这看上去就像是T是string和int的“基类”，在使用MyList<T>时（相当于客户端代码），T既可以是string也可以是int，或者是其他符合约束的类型，但在设计时，我们对这一切毫无所知。

您是否也觉得这是多态性的一种体现呢？

再来看看十分经典的Swap<T>的例子。

public class Swapper
{
    private static void Swap<T>(ref T o1, ref T o2)
    {
        T temp = o1;
        o1 = o2;
        o2 = temp;
    }
}

Swap<T>泛型方法就像是封装了N个非泛型的Swap方法，如Swap(ref int o1, ref int o2)、Swap(ref string o1, ref string o2)等等。在类型推断特性的支持下，您甚至可以像使用非泛型方法一样来使用泛型方法。参数T在某种程度上体现了不同的参数形态，因此我们有理由认为，泛型类型T体现了参数的多态性。

委托体现了方法的多态性

委托是对拥有相同参数和返回值的所有方法的封装。只要方法拥有同样的参数列表和返回值，委托都认为它们属于同一“类型”的方法，可以添加到同一个委托链表中。

public delegate void FooDelegate(List<string> list, string str);

public class DelegateTest
{
    public void AddToList(List<string> list, string strToAdd)
    {
        list.Add(strToAdd);
    }

    public static void PrintIfContains(List<string> list, string strToCheck)
    {
        if (list.Contains(strToCheck))
            Console.WriteLine("The list contains " + strToCheck);
    }
}

public class Program
{
    public static void Main()
    {
        List<string> list = new List<string>();
        list.Add("Kirin");
        DelegateTest delegateTest = new DelegateTest();
        FooDelegate fooDelegate = new FooDelegate(delegateTest.AddToList);
        fooDelegate += new FooDelegate(DelegateTest.PrintIfContains);
        fooDelegate(list, "麒麟.NET");
        Console.ReadLine();
    }
}

在上例中，FooDelegate委托封装了参数为List<string>和string，并且没有返回值的方法。任何符合上述约束的方法，在FooDelegate中一视同仁。如，AddToList实例方法与PrintIfContains静态方法除了参数列表与返回值相同外，内部实现完全不同，但是它们却可以添加到同一个委托链表中。也就是说，同一个委托，可以定义并调用不同的方法（约束相同而实现不同）。

您是否也认为这是方法的多态性的一种体现呢？

小结

我们通常所讨论的多态，就是指子类对父类方法的重写（虚方法）或覆盖（非虚方法），这样的理解未免过于狭隘。.NET强大的特性能够实现其他语言中无法实现的多态性。如本文所列举的泛型和委托。您是否认同笔者的观点呢？如果认同，您是否还能举出其他的例子呢？

您可能觉得本文缺乏技术含量。的确是的，本文并不包含多么高深的技术和思想，而只是笔者最近学习过程中一些琐碎的领悟。如果能够帮助到您，将是笔者的荣幸。

本文主要介绍VS中的常用功能（笔者常用的）在Eclipse下如何实现，希望对转战到Eclipse的原.NET程序员有所帮助。

1.自动换行

我相信很多VS使用者并不常用自动换行功能，而是通过手工输入回车的方式进行换行，这样的代码才够清晰。但本人实在是习惯了VS中的自动换行。因为并不是所有的程序员都会通过手工回车换行，而且即使手工换行了，不同分辨率的桌面看到的代码也可能是迥异的。这往往会导致令我深恶痛绝的横向滚动条。因此在我的VS里，必然选中自动换行并显示自动换行符号（Tools—>Options—>Text Editor—>All Languages—>Word wrap和Show visual glyphs for word wrap）。

令人失望的是，Eclipse中没有相应的功能，但我们可以通过格式化代码来实现。Window—>Preferences—>Java—>Code Style—>Formatter—>点击Show按钮—>Line Wapping选项卡—>在Maximum line width中设置每行的最大行宽，然后用Ctrl+Shift+F来实现自动换行。

但是这样的自动换行方式会修改源文档，当您只想阅读代码而不想修改时，这样的方式必然会带来麻烦。

2.Open Declaration

我们在阅读代码时，最常使用的一个IDE功能就是跳转到当前成员（包括参数、字段、属性、方法等）或类（还包括结构、枚举、委托等）的定义处。在VS中，我们可以右键点击该成员或类，然后选择“Go To Definition”。在Eclipse中，我们可以右键点击成员或类，然后选择“Open Declaration”（快捷键F3）。此外，还可以选择“Open Type Hierarchy”（快捷键F4），查看类型的层次结构。

3.References

与“Go To Definition”相对应的，在VS中我们可以选择右键菜单中的“Find All References”来查找当前成员的所有引用。在Eclipse中，我们需要选中一个成员或类，选择右键菜单中的“References”菜单，然后选择一个查找级别（Workspace、Project或Hierarchy），查找的结果将显示在“Search”视图中。

然而Eclipse查找出的所有引用并不能显示具体的语句，而只能具体到方法名称。这给查找带来了一定的不便。比如我们想在解决方案中查找哪些类实现了IFoo这个接口，在Eclipse中查找出来的是所用引用了IFoo的地方，而在VS中我们可以一目了然地发现那些语句使用了“: IFoo”。

4. Search

在编程时使用Ctrl+F查找某个关键字是不可避免的。VS中的Ctrl+F功能十分强大，它甚至允许我们选择查找的范围，如当前文档，还是整个解决方案。初用Eclipse时，会发现其Ctrl+F十分低能，只能检索当前文档的内容。其实，我们在Eclipse真正常用的不是Ctrl+F的“Find/Replace”，而是“Search”。

在Eclipse中点击“Search”菜单，选择“Search”选项（快捷键Ctrl+G），将打开Search界面。如下图所示：

你会发现其强大之处：通配符、搜索的类型、限制等等。你马上会联想到前面所说的Open Declarations和References都是实际上都是Search的一部分。

相信与本书前两个版本一样，第三版也是绝对值得期待的经典之作。

Eclipse体系结构

Eclipse的体系结构图如下。

Platform Runtime是整个架构的核心，其他部分实质上都属于插件范畴。Eclipse采用动态加载机制，即只有需要的才加载，这样可以降低启动时间，提高资源使用效率。

Workspace主要负责管理用户资源，如创建项目的管理、文件变更等，并通知其他插件关于资源的变更信息。

Workbench是Eclipse提供的用户界面，它使用SWT（标准窗口工具包）和JFace（建立在SWT之上的UI部件）构建。

Help允许以HTML文件形式添加文档，并提供了一个附加的导航结构以便用户使用帮助功能搜索相关信息。

Team负责提供版本控制和配置管理支持。它根据需要添加视图，以允许用户与所有使用的任何版本控制系统交互。大多数插件都不需要与Team交互，除非它们提供版本控制服务。

JDT提供了用于编辑、查看、编译、调试和运行Java代码的专门插件。PDE构建于Eclipse平台和JDT之上，提供了专门开发插件的工具。

什么是RCP

RCP摆脱了失败的AWT和Swing，是一套基于SWT和JFace的图形界面引擎。RCP在本质上是Eclipse插件，它提供丰富的界面控件，使得基于 Java 开发桌面应用也变得容易了很多。

概念解析

上一篇随笔中提到了很多RCP概念，如Workbench、WorkbenchWindow、Advisor等，它们具体是干什么的呢？下面我将试着对这些概念进行解释。

Display

应用程序一般只需要一个Display对象，该对象实际上是一个SWT对象，代表了底层图形系统的实现。Display的主要任务是事件处理，它负责从操作系统的事件队列中读取事件，传递给RCP的事件监听器以便完成具体的任务。需要注意的是，Display对象不代表应用程序窗口的任何可视控件，在应用程序主窗口打开之前，Display是不可获得的。应用程序主窗口打开之后，才可以通过一个被称作Shell的对象获得。Display对象的获得方法如下。

Display display = new Display();

或者：Display display=Display.getCurrent();

Shell

每一个窗口都有一个Shell对象。Shell对象代表了与用户交互的窗口框架，并处理与窗口关联的诸如移动、改变大小等常见行为。Shell对象的获得方法：

Display display=Display.getCurrent();

Shell shell = new Shell(display);

或者：Shell shell=Display.getCurrent().getActiveShell();

Workbench

Workbench是工作台，通俗地说就是代表用户界面的UI元素。工作台上有各种窗口、图标、按钮和控件，用户可以在工作台上做各种操作。获得工作台对象的方法：

IWorkbench wb=PlatformUI.getWorkbench();

工作台对象有两个方法也许很有用：

    wb.restart()，关闭应用程序并立即重新启动。

    wb.close()，正常关闭应用程序，等同于ActionFactory.QUIT_ACTION。

Advisor

Advisor是建议者，用户主界面宽度、高度、图标、菜单、工具栏、颜色、操作等等配置方案需要Advisor来提出“建议”。Eclipse提供了3种类型的Advisor：

    1. WorkbenchAdvisor。应用程序级别，Eclipse3.0开始引入的全新类。每一个应用程序只有一个 Workbench，WorkbenchAdvisor负责该工作台生命周期的管理，例如启动、关闭工作。WorkbenchAdvisor也负责该 Workbench的异常处理，并负责向Workbench提供一些重要参数，例如可以指定该Workbench的初始透视图。

    2. WorkbenchWindowAdvisor。窗口级别。每一个窗口都有一个WorkbenchWindow- Advisor 实例。WorkbenchWindowAdvisor 负责具体窗口生命周期的管理，例如状态栏、工具栏、菜单、窗口标题、窗口大小和各种控件等等，也可以处理窗口的各种事件例程。

    3. ActionBarAdvisor。窗口级别。每一个窗口都有一个ActionBarAdvisor实例。ActionBarAdvisor负责管理窗口的菜单栏、状态栏、工具栏的外观和行为。

IWorkbenchSite

workbench及其part，包括part中的page，的通用接口。

IWorkbenchPartSite：workbench和workbench part之间主要的接口，不直接实现。

PartSite：实现IWorkbenchPartSite。PartSite的生命周期：

1. 构建site。

2. 构建part并保存在part中？？

3. site调用part.init()。

4. 构建pane并保存在site中。

5. 构建part的action bar并保存在site中。

6. pane添加到presentation中。

7. 创建pane和part的SWT widget。

8. 激活site，使actions可见。

IWorkbench：

Workbench是Eclipse用户界面中最底层的对象，它建立在Display之上，包含1个或多个IWorkbenchWindow，用于向最终用户呈现信息。当你的workbench插件被激活的时候，eclipse平台将为之创建一个实例，在平台的整个生命周期中，只允许出现该workbench的唯一实例

IWorkbenchWindow：

上面getActiveWorkbenchWindow()得到的就是IWorkbenchWindow。IWorkbench利用其包含的IWorkbenchWindow向终端用户展现信息。workbench window是workbench中最顶级的window。包括菜单栏、工具栏、状态栏以及一个用来显示IWorkbenchPage的主区域。每个IWorkbenchWindow包含0个或多个IWorkbenchPage，但是同一时刻只允许一个IWorkbenchPage被激活并向最终用户显示。

IWorkbenchPage

IWorkbenchPage的功能就是组织一个或多个IWorkbenchPart（IEditorPart或IViewPart）显示在一个IWorkbenchWindow中,最终呈现给最终用户。IWorkbenchPage包含0个或多个IEditorPart或IViewPart，这些IEditorPart和IViewPart完全被包含在这个IWorkbenchPage并且不能与其它的IWorkbenchPage共享。IWorkbenchPage上定义的Layout和ActionSet就是我们常说的透视图——perspective了。

WorkbenchPage：workbench中view和editor的集合。

    IWorkbenchPage.findView(viewName)可以得到IViewPart。

    IWorkbenchPage.findEditor(IEditorInput)可以得到IEditorPart。

获取WorkbenchPage的方法：

    ViewPart.getViewSite().getPage()。（getViewSite()得到的是IWorkbenchPartSite）

    getDefault().getWorkbench().getActiveWorkbenchWindow().getActivePage()。

    PlatformUI.getWorkbench().getActiveWorkbenchWindow().getActivePage()。

IWorkbenchPart

WorkbenchPart是所有workbench parts的基类，如ViewPart和EditPart。不直接继承。

IWorkbenchPart就是上面提到的IEditorPart和IViewPart，它也只包含这两个子类型。

IViewPart常常被用于导航信息的层次结构,例如我们的workspace,或者用来打开一个编辑器,或者用来显示这个编辑器的某些属性

IEditorPart多被用来编辑或浏览一个文档或一个输入的对象,而这个输入的对象必须是一个IEditorInput,IEditorPart遵循的就是打开-保存-关闭的生命周期模型

IWorkbenchPart的生命周期模型：

    创建IWorkbenchPart扩展点

        实例化IWorkbenchPart

        创建一个IWorkbenchPartSite

        调用part.init(site)

    IWorkbenchPart成为可见:

        调用part.createControl(parent)绘制 IWorkbenchPart

        激活partOpened event

    IWorkbenchPart被激活或者取得焦点:

        调用part.setFocus()

        激活partActivated event

    IWorkbenchPart被关闭:

        如需要保存,完成保存

        解除IWorkbenchPart的激活状态

        激活partClosed event

        从界面上移除IWorkbenchPart

        调用part.dispose()

PartPane：ViewPane和EditorPane的基类。

PartSite：ViewSite和EditorSite的基类，实现IWorkbenchPartSite。

IEditorInput：是editor input轻量级的描述符（descriptor），类似文件名，但更加抽象。它并不是一个model，而是为IEditorPart的model源的描述。

小结

本文介绍了一些RCP的基本概念，在接下来的随笔中将通过实例讲解如何进行RCP开发。

国外的大牛们大多推崇将日期分隔为年、月、日，通过扩展IRouteConstraint来对年月日分别进行判断。引用老赵的话来说，“无论从易用性还是通用性等角度来看，这种做法都是下下之策。说实话，这样的做法其实并没有跳出框架既有功能给定的圈子，它只是通过“迎合框架”来满足自己的需求，而不是让框架为我们的需求服务。”

其实要实现这样的需求也不难，只需要对老赵的方案稍微修改一下就可以了。我们将URL定义为Demo/Date/{year}/{month}/{day}，然后在生成RouteData时，将year、month、day组合成date；生成路径时，再将date划分为year、month、day。

新建一个DateFormatRoute类，让它继承自RouteBase。在GetRouteData方法中拼接年月日，其余方法与老赵的相同。

public override RouteData GetRouteData(HttpContextBase httpContext)
{
    var routeData = route.GetRouteData(httpContext);
    if (routeData.Values["year"] != null)
    {
        string date = routeData.Values["year"].ToString() + routeData.Values["month"].ToString() + routeData.Values["day"].ToString();
        routeData.Values.Remove("year");
        routeData.Values.Remove("month");
        routeData.Values.Remove("day");
        routeData.Values["date"] = date;
    }
    else
    {
        return null;
    }

    var valuesModified = new Dictionary<string, object>();
    foreach (var pair in routeData.Values)
    {
        var key = pair.Key;
        IRouteFormatter formatter = null;
        if (this.formatters.TryGetValue(key, out formatter))
        { 
            object o;
            if (formatter.TryParse(pair.Value, out o))
            {
                valuesModified[key] = o;
            }
            else
            {
                return null;
            }
        }
    }

    foreach (var pair in valuesModified)
    {
        routeData.Values[pair.Key] = pair.Value;
    }
    return routeData;
}

在GetVirtualPath方法中，再将年月日分解到各个segment中。

public override VirtualPathData GetVirtualPath(RequestContext requestContext, RouteValueDictionary values)
{
    var routeValues = new RouteValueDictionary();
    foreach (var pair in values)
    {
        var key = pair.Key;
        IRouteFormatter formatter = null;
        if (this.formatters.TryGetValue(key, out formatter))
        {
            string path;
            if (formatter.TryToString(pair.Value, out path))
            {
                routeValues[key] = path;
            }
            else
            {
                return null;
            }
        }
        else
        {
            routeValues[key] = pair.Value;
        }
    }
    if (routeValues["date"] != null)
    {
        string s = routeValues["date"].ToString();
        routeValues.Remove("date");
        routeValues["year"] = s.Substring(0, 4);
        routeValues["month"] = s.Substring(4, 2);
        routeValues["day"] = s.Substring(6, 2);
        
    }

    return route.GetVirtualPath(requestContext, routeValues);
}

最后，修改Global.asax

routes.Add(
    "Demo.Date",
    new DateFormatRoute(
        "{controller}/{action}/{year}/{month}/{day}",
        new RouteValueDictionary(), // defaults
        new Dictionary<string, IRouteFormatter>
        {
            {"controller", new RegexFormatter("Demo")},
            {"action", new RegexFormatter("Date")},
            {"date", new DateTimeFormatter("yyyyMMdd")}
        },
        new RouteValueDictionary(), // constaints
        new RouteValueDictionary(), // data tokens
        new MvcRouteHandler()));

打开浏览器测试一下，URL和链接都显示正常。

PS：对于URL Routing的扩展，实在是想找一个别的例子来进行探讨。但稍微复杂一点的类型也不可能通过URL体现出来，而稍微简单一点的，用正则表达式就可以约束了。所以最后只要生硬的来修改老赵的示例了……

也可能是我的思路还没有打开，大家有没有什么比较好的思路？欢迎在这里讨论。

该程序集（Microsoft.Web.Mvc.dll）中包含众多扩展方法，以前的CTP版本都有，但在正式版发布的时候，去掉了这部分。据说是为了保持版本的稳定性。其实，可能是由于deadline到了，产品“减配”了吧：）。

我们仍然可以手动下载该程序集，并在项目中添加引用。然后在web.config里添加Microsoft.Web.Mvc命名空间。

<namespaces>
    <add namespace="System.Web.Mvc"/>
    <add namespace="System.Web.Mvc.Ajax"/>
    <add namespace="System.Web.Mvc.Html"/>
    <add namespace="System.Web.Routing"/>
    <add namespace="System.Linq"/>
    <add namespace="System.Collections.Generic"/>
    <add namespace="Microsoft.Web.Mvc"/>
</namespaces>

老赵在做日期转换时，使用了DateTime.TryParseExact，那么我们就来看看这个TryParseExact是否在正常工作。

DateTime output;
DateTime.TryParseExact("2009-06-04", "yyyy/MM/dd", null, DateTimeStyles.None, out output);
Console.WriteLine(output.ToString());

以上代码的输出结果果然让人大跌眼镜，日期居然能正确转换！

难道TryParseExact的第二个参数format没有作用吗？将/改成.，居然又不能转换了：

看来是/这个符号的问题。请出Reflector，将mscorlib.dll反编译，找到DateTime.TryParseExact方法，一步一步跟进去。发现如果该方法的IFormatProvider参数为null，将获取当前线程的CultureInfo的DateTimeFormat属性作为IFormatProvider，然后在DateTimeParse.ParseByFormat方法中，遇到format参数的/字符时，会比较输入日期字符串的当前字符是否为当前DateTimeFormatInfo的DateSeperator，如果是，则返回true，即允许转换，如果不是则返回false。

CultureInfo cultureInfo = Thread.CurrentThread.CurrentCulture;
Console.WriteLine(cultureInfo.DateTimeFormat.DateSeparator);

而以上代码输出的恰恰为-，也就是说当前线程的区域信息中，日期分隔符即为-，因此，转换得以成功。

如果您使用

DateTimeFormatInfo dtfi = new CultureInfo("zh-CN", false).DateTimeFormat;
DateTime output;
DateTime.TryParseExact("2009-06-04", "yyyy/MM/dd", dtfi, DateTimeStyles.None, out output);
Console.WriteLine(output.ToString());

则转换失败，因为在初始化CultureInfo时，第二个参数为false意味着不使用用户选定的区域性设置，而使用默认的设置，这时的DateSeparator为/

至此，谜底全部解开。

// 小贴士：遇到.NET Framework内部实现的问题时，使用Reflector反编译类库并查看源代码的方式，往往可以解决您的问题：）

ASP.NET MVC设计的主要原则之一是可扩展性。处理管线（processing pipeline）上的所有（或大多数）东西都是可替换的。因此，如果您不喜欢ASP.NET MVC所使用的约定（或缺乏某些约定），您可以创建自己的服务来支持您的约定，并将其注入到主管线中。

在本文中，我们将从管线开始直到视图呈现，逐一向您展示每个ASP.NET MVC开发者都必须了解13个扩展点。

1.RouteConstraint

通常情况下你可以使用正则表达式对url参数进行约束，但如果您的约束不仅仅取决于单一参数，您可以实现IRouteConstrains的方法，并在其中添加你的验证逻辑。

比如对日期的验证，url中可能会包含年、月、日，而你需要验证这三者是否可以组合成一个有效的日期。

2.RouteHandler

RouteHandler是在路由选择之后进行处理的组件，它并不仅仅针对ASP.NET MVC。显然，如果您改变了RouteHandler，那么对请求的处理将不再使用ASP.NET MVC，但这在您使用其他HttpHandler或经典的WebForm进行路由处理时却是非常有用的。

3.ControllerFactory

ControllerFactory是基于路由的组件，它选择正确的controller并对其实例化。default factory会查找实现了IController并且以Controller结尾的类，然后通过反射使用无参构造函数进行实例化。

但如果您希望使用依赖注入，就不能再使用default factory，而必须使用支持IoC的controller factory。MvcContrib和Ninject Controller Factory都包含支持IoC容器的controller factory。

4.ActionInvoker

ActionInvoker顾名思义是负责调用（invoke）action的。默认的action invoker通过方法名、action名或其他可能的selector attribute来查找action，然后调用action方法以及定义的filter，最终执行得到action result。

你会发现大部分执行管线存在于ControllerActionInvoker类的逻辑之中。因此，如果希望改变这些约定，如action方法的选择逻辑、http参数映射到action参数的方式、选择和执行filter的方式等，您需要扩展该类并重写需要修改的方法。

可以参阅NinjectActionInvoker I developed to allow injection of dependencies inside filters。

5.ActionMethodSelectorAttribute

使用默认的action invoker时，action的选择是基于名称的。您也可以实现自己的Method Selector以改善对于action的选择。在框架中已经包含了AcceptVerbs特性，它允许您指定使用哪一个HTTP Verb来处理action的响应。

例如，您也许会希望基于浏览器所支持的语言或浏览器类型（如移动设备的浏览器或桌面浏览器）来进行action的选取。

6.AuthorizationFilter

这种过滤器是在action执行之前执行的，用来确保请求是有效的。

框架中已经包含了一些autorization过滤器，最有名的莫过于Authorize特性，它用来检查当前用户是否允许执行该action。另一个是用来阻止CSRF攻击的ValidateAntiForgeryToken。如果您希望实现自己的authorization，那么必须实现接口。例如，日期中的小时。

7.ActionFilter

Action Filters在action执行前后执行。OutputCache过滤器是几个核心过滤器之一。这可能是您最有可能使用的扩展点，并且在我看来，controller只关心它的主要工作，而view所需要的所有其他数据都必须从action过滤器内部获取，这样的实现对于一个组织良好的view来说，是十分关键的。

8.ModelBinder

默认的model binder使用参数名称进行HTTP参数到action方法参数的映射。例如，http参数user.address.city将映射到方法参数user的Address属性的City属性。DefaultModelBinder也同样适用于数组和其他列表类型。

更进一步来说，例如，您可能希望从数据库中进行检索，直接根据person的id将其转换为Person对象。Timothy Khouri（网名SingingEels）在他的文章Model Binders in ASP.NET MVC中更好的阐述了这种方法。他的代码基于Preview 5，但其理念是一样的。

9.ControllerBase

所有的Controller均继承自基类Controller。要想在action中封装自己的逻辑和约定，创建自己的父类使所有Controller继承自该类，是一种很好的方式。

10.ResultFilter

与ActionFilter类似，ResultFilters在ActionResult前后执行。OutputCache过滤器也可以作为ResultFilter的示例。另外，比较常用的诠释这种过滤器的示例是日志记录。如果您希望在页面返回给用户时记录日志，可以编写自定义的RenderFilter，在ActionResult执行之后记录日志。

11.ActionResult

ASP.NET MVC提供了很多result用来呈现视图、JSON、纯文本、文件并重定向到其他action。如果您需要其他类型的result，可以自定义ActionResult，并实现ExecuteResult方法。例如，如果您希望将PDF文件作为结果发送，您需要使用PDF库编写能够生成PDF的ActionResult。又如RSS feed，可参见how to write a RssResult in this post。

12.ViewEngine

您可能不需要编写自己的view engine，但您也许可以考虑使用其他引擎来替代默认的WebForm view engine。在我看来，最有趣的引擎就是Spark。

如果您确实希望编写自己的view engine，可以看一下Brad Wilson的文章: Partial Rendering & View Engines in ASP.NET MVC。

13.HtmlHelper

视图必须十分简单整洁，它们只能包含html标记并调用HtmlHelper的辅助方法。视图中不能包含任何代码，所以辅助方法必须十分方便，使您可以将代码从视图中提取出来，放到一个可测试的环境中去。正如Rob Conery所说：如果有if，就构造辅助方法（If there's an IF, make a Helper）。

什么是HtmlHelper辅助方法？其实就是HtmlHelper类的扩展方法，这是唯一的要求。

你可以从Rob的文章Avoiding Tag Soup中了解到为什么说HtmlHelper是封装视图中代码的好方法。

在您的应用中该使用哪个呢？

正如您所猜测的那样，并不是所有的应用都需要扩展以上的13个扩展点。最可能在所有应用中进行扩展的是ActionFilter和HtmlHelper。另外，您很可能会使用其他人编写的扩展，如使用了IoC容器的ControllerFactory或用来摆脱WebForm的ViewEngine。

但是，学习这些扩展点并进行尝试是十分重要的，这样您才会做出选择，并随时准备在必要的时候使用这些强大的扩展点。下周我将发表一些文章来阐述如何使用这些扩展点。

如果您想详细了解更多关于该话题的内容，可以考虑购买即将出版的Beginning ASP.NET MVC（我是作者之一）或Professional ASP.NET MVC（ASP.NET MVC开发团队编写）或ASP.NET MVC in Action （Jeffrey Palermo和Ben Scheirman著）。

我是否遗漏了某些您认为重要的扩展点呢？您是否使用过我上面提到的扩展点呢？我很想听听您所遇到的场景。

第一个RCP程序

打开Eclipse，新建一个Plug-in Project，点击Next。在Project name文本框中输入项目名称net.kirin.rcp.hello，如下图所示。

点击Next，如下图所示，在“Would you like to create a rich client application？”后面选中Yes。其余均可保留默认值。

点击Next，选择Hello RCP模板。

点击Next，打开如下对话框，各项均可保留默认值。

点击Finish，将创建结构如下的项目。

双击MANIFEST.MF文件，将打开一个名为Overview的界面，点击Launch an Eclipse application，

结果如下图所示。

这就是我们的第一个RCP程序。当然，我们没有写一行代码，完全是Hello RCP模板自动为我们创建的。

代码解析

可以看到，RCP模板自动为我们创建了Application.java、ApplicationActionBarAdvisor.java、ApplicationWorkbenchAdvisor.java、ApplicationWorkbenchWindowAdvisor.java、Perspective.java这5个类。下面我们对这5个类进行逐一分析。

Application类

在普通的Java程序中，总有一个main()方法作为应用程序的入口点。而RCP程序的入口点则是Application类。打开Application.java文件，可以看到该类实现了IPlatformRunnable接口，入口方法如下所示：

public Object run(Object args) throws Exception {
    Display display = PlatformUI.createDisplay();
    try {
        int returnCode = PlatformUI.createAndRunWorkbench(display, new ApplicationWorkbenchAdvisor());
        if (returnCode == PlatformUI.RETURN_RESTART) {
            return IPlatformRunnable.EXIT_RESTART;
        }
        return IPlatformRunnable.EXIT_OK;
    } finally {
        display.dispose();
    }
}

run()方法为IPlatformRunnable接口所定义的方法，在RCP程序启动时，会首先执行该方法。Application首先创建一个Display对象， 然后调用PlatformUI.createAndRunWorkbench()方法创建并启动工作台，这将打开应用程序主窗口，并使该窗口处于持续打开状态。应用程序开始处理用户的鼠标单击、鼠标移动、按键等各种事件，直到用户关闭程序退出，这就是所谓的事件循环。当然，在关闭之前，必须用display.dispose()销毁Display对象以释放资源。

ApplicationWorkbenchAdvisor类

在PlatformUI.createAndRunWorkbench()方法中，还传入了一个新建的ApplicationWorkbenchAdvisor对象。它类负责应用程序生命周期管理，它继承自WorkbenchAdvisor类。开发人员可以在该类中实现程序启动或者关闭时的某种处理。该类的具体实现只是给用户一个初始的视图界面而已，还需要配合WorkbenchWindowAdvisor、ActionBarAdvisor才能构成一个较为完整的用户界面。

打开ApplicationWorkbenchAdvisor.java文件，代码如下：

public class ApplicationWorkbenchAdvisor extends WorkbenchAdvisor {

    private static final String PERSPECTIVE_ID = "net.kirin.rcp.hello.perspective";

    public WorkbenchWindowAdvisor createWorkbenchWindowAdvisor(IWorkbenchWindowConfigurer configurer) {
        return new ApplicationWorkbenchWindowAdvisor(configurer);
    }

    public String getInitialWindowPerspectiveId() {
        return PERSPECTIVE_ID;
    }
}

createWorkbenchWindowAdvisor()方法初始化在主界面显示的透视图，并返回ApplicationWorkbenchWindowAdvisor对象。

ApplicationWorkbenchAdvisor还包含一些比较重要的方法：

• initialize：最先调用。在窗口打开之前调用，可以用来处理初始化配置工作。
• preStartup：initialize之后、第一个窗口打开之前调用，可以用来处理临时或者可选处理工作。
• postStartup：第一个窗口打开之后但启动事件循环之前调用，可以用来进行那些需要自动处理的工作，例如弹出一个提示窗口。
• preShutdown：事件循环结束之后但窗口关闭之前调用，可以用来进行保存数据、关闭数据库服务器等处理工作。
• postShutdown：窗口关闭之后调用，可以用来进行保存应用程序状态、清除initialize创建的对象等处理工作。

ApplicationWorkbenchWindowAdvisor类

在ApplicationWorkbenchAdvisor类中创建了一个ApplicationWorkbenchWindowAdvisor对象。它主要负责窗口生命周期的管理，例如状态栏、工具栏、菜单、窗口标题、窗口大小和各种控件等等，也可以处理窗口的各种事件例程。其主要代码如下：

public class ApplicationWorkbenchWindowAdvisor extends WorkbenchWindowAdvisor {

    public ApplicationWorkbenchWindowAdvisor(IWorkbenchWindowConfigurer configurer) {
        super(configurer);
    }

    public ActionBarAdvisor createActionBarAdvisor(IActionBarConfigurer configurer) {
        return new ApplicationActionBarAdvisor(configurer);
    }
    
    public void preWindowOpen() {
        IWorkbenchWindowConfigurer configurer = getWindowConfigurer();
        configurer.setInitialSize(new Point(400, 300));
        configurer.setShowCoolBar(false);
        configurer.setShowStatusLine(false);
        configurer.setTitle("Hello RCP");
    }
}

preWindowOpen()方法在窗口控件创建之前调用，用来配置窗口，如设置窗口大小、工具栏、状态栏和标题等。createActionBarAdvisor创建了一个ApplicationActionBarAdvisor对象。

其它比较重要的方法还包括：

• postWindowRestore：当窗口根据上一次的保存状态恢复创建之后调用，可以用来调整调整窗口恢复状态。
• postWindowCreate：窗口创建之后调用，可以用于调整窗口。
• postWindowOpen：窗口已经打开之后调用，可以用来注册窗口监听，例如在此方法中实现系统托盘。

ApplicationActionBarAdvisor类

ApplicationActionBarAdvisor主要负责管理窗口的菜单栏、状态栏、工具栏的外观和行为。其主要代码如下：

public class ApplicationActionBarAdvisor extends ActionBarAdvisor {

    public ApplicationActionBarAdvisor(IActionBarConfigurer configurer) {
        super(configurer);
    }

    protected void makeActions(IWorkbenchWindow window) {
    }

    protected void fillMenuBar(IMenuManager menuBar) {
    }
    
}

makeActions()方法用来注册菜单或工具栏的动作。fillMenuBar()方法用来添加菜单栏。

其它比较重要的方法还包括：

• fillCoolBar：添加工具栏
• fillStatusLine：添加状态栏

Perspective类

Perspective类主要负责界面布局的安排，其代码如下：

public class Perspective implements IPerspectiveFactory {

    public void createInitialLayout(IPageLayout layout) {
    }
}

createInitialLayout()方法通常用于创建初始的界面布局。

参考资料

1. Eclipse从入门到精通

2. Eclipse RCP应用系统开发方法与实战

3. Eclipse RCP - Tutorial with Eclipse 3.4

4. 使用Eclipse RCP进行桌面程序开发（一）：快速起步

小结

本篇作为《深入浅出Eclipse RCP》系列的开篇，介绍了如何使用Hello RCP模板创建最简单的RCP程序，并对自动生成的5个类进行了解析。如果您是RCP的初学者，也许会对本文中出现的一些概念改到困惑。没有关系，我将在接下来的随笔中介绍RPC的基本架构以及Workbench、Action、Perspective等概念。

于是用心爱的63拍了几张pp，上图！

书皮秉承了图灵一贯的风格。

扉页有“样书”的章。

译者介绍，最后一个译者就是在下啦。什么？看不清？赶快去买一本吧，呵呵。

对于Stephen Walther的ASP.NET揭秘系列，我早在一年前就进行过介绍和推荐，没想到这次居然有机会翻译将自己带入ASP.NET殿堂的名著的后续版本，实在感到万分荣幸，以及万分担忧（怕自己翻译不好啊……）。

总的来说，《ASP.NET 3.5 揭秘》上下两卷延续着前两版的风格和质量，循序渐进、深入潜出、示例丰富。作为译者，不敢亵渎经典，唯有小心翼翼，字句斟酌，力求做到信、达、雅。好在有上一版四位MVP的卓越工作，他们流畅的翻译使我少走了很多弯路。图灵公司的陈兴璐和王军花两位编辑认真负责，保障了两卷书的顺利出版。

这一版《揭秘》新增了300也的内容，包括：

1. ListView和DataPager

2. LINQ to SQL

3. ASP.NET AJAX

4. 全新的示例程序

同时删除了Web部件的相关内容。

本书是一部全面的ASP.NET工具书，尤其适合广大初学者。如果大家对于本书有什么意见或建议，请在留言中列出。

为什么CLR不允许多重继承？

这个问题乍看起来也许很小白，不允许就是不允许，哪来那么多为什么呢？你以为你是小沈阳啊？

呵呵，不好意思，我还没完，接下来的问题是，为什么所有的类都继承自System.Object？为什么不能实例化抽象（包括抽象类和接口）？为什么接口不能有实现？……对于这些问题，我们真的认真思考过吗？

其实，面向对象思想，是对现实世界最好的诠释。一切皆对象，在OO中如此，在现实生活中亦是如此。在虚拟的程序中，我们经常会对现实中的各种事物进行建模，于是“人”、“汽车”等事物就成了代码中的Person和Car。我们为什么会自然而然地进行这样的转换呢？这正是面向对象编程思想的魅力所在。“人”和“汽车”在现实中都代表一类事物，他们有相同的行为和属性，这就是面向对象中类的概念。

许多年前，当我开始接触面向对象的时候，我并不能理解书本上晦涩的概念。然而随着CS水平的日益提高，我也逐渐对面向对象有了自己的认识。AK47就是一个类，当你按下B+4+1的时候，就初始化了这样一个实例。它有自己的属性：大小、颜色、子弹数量、换弹时间；也有自己的行为：发射、换子弹。此后，再将面向对象与现实世界相联系，我逐渐理解了前面提到的那几个问题。他们的答案都是一个：因为现实世界就是这个样子的。

为什么所有的类都继承自System.Object？因为现实世界所有的事物都可以归为一个绝对抽象的基类。生物、非生物都是这个基类的派生。外形、运动等等就是这个基类的属性或行为。

为什么不能实例化抽象？因为现实世界中不存在抽象的具体事物。抽象是从众多的事物中抽取出共同的、本质性的特征，它并不是某一具体的事物。换句话说，如果存在可以具体化的抽象，那么这个抽象就不是真正意义上的抽象了，它对于事物共性的提取，是错误的。

为什么不允许多重继承？因为现实世界种不存在多重继承。派生类与基类的关系是IS-A，即派生类是一个基类。人就是动物，动物就是生物，不可能同时还是非生物。任何一个事物都有所属，我们把动物植物按照一定的纲、门（汗……）分类，就是这个原因。如果存在A既是B又是C，只能说明B是C或者C是B，如果B和C没有继承关系，那么你说A到底是B还是C呢？当然，随着科技的发展，新的事物层出不穷，有些无法无法按照单继承分类的事物，其实就是一个新的事物。比如，水路两用车，到底是属于车呢，还是属于船呢？其实都不是，它就是水路两用的交通工具，自成一派。

抽象类，还是接口？

抽象类和接口都属于以上提到的抽象，两者的在语法上的区别Anytao和其他园友已经总结的差不多了，不再赘述。我主要想和大家讨论一下在设计时如何选择抽象类和接口。

我的原则是，尽量按照现实世界的语义来判断。

众所周知，派生类与抽象类的关系是IS-A，实现类与接口的关系是CAN-DO。这就说明抽象类与子类之间的所属关系较接口来说更加明确。接口只是行为方式上的一种契约，一个类实现了一个接口，只能说明该类具有该接口所约定的行为，但它并不属于该接口（事实上，接口也无法成为其他类的所属者），因此我们把对抽象类的派生叫做继承，而把对接口的派生叫做实现。例如，IComparable接口为所有可进行比较的类提供一个抽象的约定，但也仅仅局限于该约定。在语义上，“可以比较的”并不是某一类事物全部行为和属性的抽象，因此并不能够成为其派生类的父类。

人和汽车肯定不属于一类事物，但是他们却可以有相同的行为，即Move。那么Person类和Car类虽然继承自不同的基类，但它们却可以实现同一个接口IMoveable（该接口仅包含一个Move方法）。

因此，在设计时，我们需要思考这个抽象是代表的一类事物，还是代表一类行为或属性。如果是一类事物，就设计为抽象类；如果是一类行为或属性，就设计为接口。如果发现某个子类不得不继承两个基类，那么就必须审视一下这两个基类的设计是否合理，是否应该提取一些接口出来，或者是否应该重新设计一个基类。

现在来回答为什么接口不能有实现的问题，因为现实世界……哎呀，哪里的砖头？……

呵呵，其实正如前面所说，接口只是一种规范的约定，它并不了解各个实现类的具体细节。抽象类Person可以对Move方法提供默认实现（走或跑），Car也同样可以（前进或倒退），但是IMoveable接口并不知道，能实现这个接口的类成千上万并且实现方式千奇百怪，要它提供一个默认的移动方式，实在强接口所难。

对于命名的建议

对于抽象类和接口的命名规范，我的建议是：将抽象类（类也是如此）命名为名词，将接口命名为I为前缀的形容词，最好以-able为后缀。

在.NET Framework里随处可见以-able为后缀的接口，如IComparable、IDisposable……意为“可……的”，这完全复合CAN-DO的语义定义。前面的IMoveable接口如果命名为IMove，在语义上或多或少地缺少了CAN-DO的意境。

当然，这只是一种建议。只要牢记接口是“可……的”这个原则，在选择抽象类和接口时就不会感到茫然了。

总之一句话，请参考现实世界。

摘要

在本系列的第四篇中，Keyvan讨论了与MVC模式相关的单元测试的概念，以及微软是如何将这些概念应用于其ASP.NET MVC框架中的。他提出了对ASP.NET MVC应用进行单元测试必须遵循的原则和过程。

内容

• 简介
• 单元测试概述
• 为什么使用MVC？为什么使用ASP.NET MVC？
• ASP.NET MVC中的抽象与隔离
• MVC模式中的测试过程
• ASP.NET MVC Preview 2中改进的测试特性
• 其他部分
• 小结

简介

在本系列的前三篇中，我讨论了MVC模式中的主要概念、ASP.NET MVC框架以及KBlog（本系列中创建的简单Blog引擎）。目前为止，我讨论了MVC模式中三个核心组件中的两个：控制器和数据模型。

Web开发者（不止是ASP.NET开发者）对MVC模式“趋之若鹜”的主要原因是，它赋予了开发者测试Web应用的能力，使得测试变得更加简单。因此，Web应用也可以进行单元测试了。

当然，对于传统的Web应用也不是不能单元测试，只是MVC模式下要简单得多。

本节和下节的话题都是单元测试。在MVC模式中，你可以仅测试控制器类。在演示如何对MVC应用进行单元测试之前，我们先从基本概念入手。

在开始正题之前我需要指出的是，本系列前三篇是基于ASP.NET MVC框架的第一个发布版本CTP的，而本文则基于第二个CTP版本。

单元测试概述

测试驱动开发（TDD）是当今最普遍的软件开发方式。敏捷开发方法的兴起以及小型软件开发团队如雨后春笋般的增多，是TDD作为软件开发首选方法的主要原因（当然还有其他的原因）。

因为显然我不可能在这里讲述太多TDD和单元测试的东西，因此我假设读者已经有了这方面的背景。但是，一个简短的介绍还是有必要的。

TDD最核心的部分就是单元测试。单元测试是将应用划分为小的不相关的可以独立工作的单元，并对这些单元进行测试的一组技术和过程。

单元测试基于以下一些原则。首先，将应用划分为更小的更便于测试的部分。其次，这些单元彼此之间相互独立互不影响。这种独立性使得对一个单元的更改不会波及到其他单元。

单元测试对这些小的单元进行测试，看它们对于不同的环境和输入数据是否都会按预期执行。这样，全部单元测试通过之后，就可以开始下一阶段的开发了。如果你修改了其他元素或单元并破坏了现有代码（这并不稀奇），那么现有的测试将不会通过，同时发出警报。

因此，你可以反复修改重构代码而不会破坏其连贯性。这也是众多开发人员选择单元测试的主要原因。

然而，我无法对测试驱动开发和单元测试进行过多的描述，当然我也不会那么做。但我只是想说，有很多方法可以对数据层、抽象代码和Web服务进行单元测试。同时，也有很多优秀的模式和实践方面的文档，描述如何编写使单元测试过程更加简单的代码。

为什么使用MVC？为什么使用ASP.NET MVC？

Web开发是一个需要自身技术和模式的普通开发场景。由于Web开发与多项服务器技术如Web服务器属性或客户端请求细节等息息相关，软件开发者需要寻求一条途径以降低这些依赖。基于以上介绍，你知道为什么了吗？

原因就是“隔离”。我们需要降低依赖来改善隔离等级。解决方案就是引进新的开发模式（如MVC）。最著名的为MVC量身打造的技术就是Ruby on Rails，这也是Ruby之所以流行的原因之一。

Web开发技术的发展使得微软开始考虑改变ASP.NET技术以适应该模式，ASP.NET MVC Framework应运而生。

总而言之：

• 单元测试很棒（在我看来，它应该成为软件开发的一部分）。
• 单元测试需要对应用中不同的但愿进行高等级的抽象和隔离。
• 传统的ASP.NET Web Form应用对HttpContext、HttpRequest和HttpResponse之类的对象有很强的依赖。
• 微软需要在其Web开发技术中适应MVC。
• 微软需要降低所有依赖并提升隔离等级。
• 因此，考虑到隔离和抽象，微软需要构建ASP.NET MVC模式。

因此，ASP.NET MVC Framework伴随着一些主要的ASP.NET类（如HttpContext、HttpResponse或HttoRequest）的重新设计，而悄然诞生。

ASP.NET MVC中的抽象和隔离

我们需要良好的抽象和隔离，但在设计和编码时应该如何做到这一点呢？抽象类和接口为我们提供了很好的方案。

单元测试与抽象基类和接口是很紧密的，并且有很多的模式和实践。我不想在这个话题上深入下去。

当使用抽象类和接口来进行抽象时，你可以很简单地测试这些类的实例，因为他们拥有共同的主要方法。在单元测试时这是十分有用的，因为它使你能更好地控制在单元测试中扮演某些角色的类。

但是如何选择使用抽象基类还是接口呢？尽管它们都可以为我们提供抽象，但也都存在一些局限性。

我的朋友，微软ASP.NET MVC团队成员，Phil Haack，发表了一些博客解释这些局限性。并且，他们在第一个CTP版本的ASP.NET MVC Framework中所面对的接口的局限，使得他们在第二版甚至以后所有的版本中都选择了抽象基类。

• Versioning Issues With Abstract Base Classes and Interfaces
• Abstract Base Classes Have Versioning Problems Too
• The Cost Of Breaking Changes

然而从最终用户的角度来看，你不必郭宇关心这些问题。

但最终，微软在第二个发布版本的ASP.NET MVC中使用了抽象基类。

你将看到这些改变有助于你在下面的章节中对ASP.NET MVC应用进行单元测试。

微软将所有的抽象类移动到一个新的程序集System.Web.Abstractions中，你可以反编译该程序集中的类。

图1按层次和结构展示了这些类，你可以对其抽象级别有些了解。

图1

如图所示，有7组基类及其派生类。每个抽象基类都代表了一个包含很多依赖的传统的ASP.NET类。因此这种抽象有助于单元测试过程，你将在下一节中有所了解。

简而言之，我们可以将这些类归为7种类型：

• HttpSessionState
• HttpServerUtility
• HttpContext
• HtpResponse
• HttpRequest
• HttpBrowserCapabilities
• HttpCachePolicy

如你所见，所有的类型都与服务器、客户端属性和特性联系紧密。但这种抽象有助于降低依赖性并改进易测性。

MVC模式中的测试过程

ASP.NET MVC中的测试过程是什么样的呢？MVC模式的设计将应用的架构划分为相互独立的组件（模型、视图和控制器），这简化了测试的过程。其理念就是，将应用划分为这些组件以限定对控制器组件的单元测试。

换句话说，只需要测试MVC中的控制器类，这就足够了。

控制器是纯粹的程序类，与数据模型和视图（数据层和用户接口层）完全独立。这种独立性可以使你通过测试控制器来测试应用程序。

下一篇将讨论如何测试控制器。

ASP.NET MVC Preview 2中改进的测试特性

ASP.NET MVC的新版本（Preview 2）（目前的最新版本为ASP.NET MVC 1.0 RC）提供了一些新的特性帮助开发者改善测试能力。一个主要的改变就是可以在创建ASP.NET MVC项目的同时创建集成的单元测试项目。在此之前，你只能先创建ASP.NET MVC项目，然后再手工创建单元测试项目。而现在Visual Studio会询问你是否新建Visual Studio单元测试项目。

如图2所示。在创建ASP.NET MVC项目之后，将会显示该对话框询问你是否创建测试项目。

图2

当然，你可以忽略它，不创建单元测试项目。

另一方面，Visual Studio测试框架（MsTest）并不是唯一的选择。许多职业程序员选择其他测试框架如NUnit、MbUnit，他们都是.NET开发者所熟知的。

其它部分

• Building a Simple Blog Engine with ASP.NET MVC and LINQ - Part 1
• Building a Simple Blog Engine with ASP.NET MVC and LINQ - Part 2
• Building a Simple Blog Engine with ASP.NET MVC and LINQ - Part 3

小结

本系列的第四部分全部是关于单元测试的概念，它使得在ASP.NET MVC应用中进行测试驱动开发成为可能。这也是MVC模式的主要优点之一。

我先介绍了在MVC模式中进行单元测试的重要性，然后简要介绍了单元测试以及主要目标，然后深入创建ASP.NET MVC Framework的过程。这之后，讨论了抽象和隔离的必要性，以及在ASP.NET MVC Framework中是如何做到这一点的。

在这篇文章中，我没有涉及到任何关于KBlog，有关该理论概念的所有应用程序也留在了下一篇中。在使用MVC模式以及ASP.NET MVC Framework时，对单元测试概念的理解是很重要的部分。

在本系列的下一篇中，我将对KBlog中的控制器进行单元测试，对单元测试的理论进行实践。

例如：

FileInfo fi = new FileInfo("test.txt");
MessageBox.Show(fi.DirectoryName);
openFileDialog1.ShowDialog();
fi = new FileInfo("test.txt");
MessageBox.Show(fi.DirectoryName);

第一次弹出的路径为

然后弹出OpenFileDialog窗口，打开其他路径中的一个文件，弹出的路径为

如果在声明FileInfo时使用绝对路径，则不会出现这样的问题。

是不是用相对路径声明FileInfo时，会产生一个默认路径，而OpenFileDialog改变了这个默认路径呢？

答案是肯定的。FileDialog控件提供了一个RestoreDirectory属性，用来指示对话框在关闭前是否还原当前目录。代码如下：

FileInfo fi = new FileInfo("test.txt");
MessageBox.Show(fi.DirectoryName);
openFileDialog1.RestoreDirectory = true;
openFileDialog1.ShowDialog();
fi = new FileInfo("test.txt");
MessageBox.Show(fi.DirectoryName);

这样，第二次弹出的对话框就与第一次相同了。

此外，即使设置了FileDialog控件的InitialDerectory，只要RestoreDirectory设置为true，用相对路径初始化FileInfo时，默认的工作路径均为当前程序所在的路径。

该系列翻译自《ASP.NET Unleashed 3.5》第18章内容

在.NET Framework 3.5的众多新特性之中，LINQ to SQL是最重要的一个。实际上，它也许意味着自SQL诞生以来，应用程序与数据库的结合方式上最重大的一次变革。

长期以来，程序员处理未持久化数据（应用程序）和持久化数据（数据库）的方式有着天壤之别：在应用程序中，我们使用对象和属性（用C#或VB.NET创建）；而在大多数数据库中，我们使用表和字段。

不管我们的应用程序和数据库是否描述非常类似的数据，这都是事实。例如，你可能会拥有一个类和一个表，其名称均为Product，代表你的Web站点所销售的产品列表。尽管如此，在这些实体之间进行交互的语言（C#、VB.NET与SQL语言）却不尽相同。很多大公司都会拥有不同的开发人员，有的擅长C#或VB.NET，有的则专攻SQL。

程序员要花费惊人的时间来转换对象和关系型世界，而这项工作是机械和乏味的。每当我想起花费在声明这些类（包含数据库字段到属性的映射）上的时间时，我都会不寒而栗。而这些时间我本可以用来陪孩子们逛公园、看电影或遛狗，等等。

LINQ to SQL的诞生使得我们可以对SQL宣判死刑。或者更准确地说，它使得SQL语言走向幕后，我们再也不必使用SQL了。这是件好事。SQL已死！

本章是较难的一章。LINQ to SQL并非很容易理解的概念，它依赖于C#、VB.NET以及.NET Framework中引入的一些新特性，而这些特性是不易掌握的。所以，请保持耐心，做个深呼吸。我保证最后一切都会清晰起来。

本章分为4部分。在第一部分中，我们讨论C#、VB.NET和.NET Framework 3.5引入的支持LINQ的新特性。然后，你将学习如何使用LINQ to SQL实体描述数据库表。接下来，我解释如何使用LINQ to SQL执行标准SQL命令，如SELECT、INSERT、UPDATE和DELETE命令。在本章的最后部分，我将示范如何创建自定义实体类（包含数据有效性验证）。

C#和VB.NET的新特性

微软公司为C#和VB.NET引入了诸多新的语言特性，以支持LINQ to SQL工作。很多特性都使得C#和VB.NET的行为更像动态语言（如JavaScript）。尽管引入的主要动机是支持LINQ，这些新特性本身还是非常有趣的。

注意：要使用这些新特性，你需要使Web站点面向.NET Framework 3.5，确保项目中包含web.config文件。然后选择菜单选项WebsiteàStart OptionsàBuild，在Target Framework中选择.NET Framework 3.5。执行这些步骤将会修改你的web.config文件，使其引用必要的程序集并使用正确的C#或VB.NET版本。

理解自动属性

我们将探索的第一个新语言特性叫做自动属性（Automatic Properties）。不幸的是，只有C#支持该特性，VB.NET并不支持。

自动属性提供了定义新属性的快速方法。如代码清单18-1所示，类Product包含了Id、Description和Price属性。

代码清单 18-1 LanguageChanges\App_Code\AutomaticProperties.cs

public class AutomaticProperties
{
// Automatic Properties
public int Id { get; set; }
public string Description { get; set; }
// Normal Property
private decimal _Price;
public decimal Price
{
get { return _Price; }
set { _Price = value; }
}
}

注意前两个属性Id和Description，没有使用Getter和Setter，这与最后一个属性Price不同。C#编译器将为你自动创建Getter和Setter，以及与属性对应的私有字段。

你不能向自动属性中的Getter和Setter添加任何逻辑，也不能创建只读的自动属性。

自动属性怎么会和LINQ to SQL有关呢？在使用LINQ to SQL时，你为了得到数据的结构（类似SQL查询时使用select语句得到的列表），经常将类设计为仅包含数据库表的各个字段。因此，你肯定希望使用最小的工作量来创建属性列表，自动属性就是为此量身定做的。

注意：使用Visual Web Developer或Visual Studio可以向类或页面中快速添加自动属性，你只需输入“prop”并按Tab键两次。

理解初始化器

使用初始化器（Initializers）可以减少实例化类的工作量。例如，假设你拥有如代码清单18-2（C#）或代码清单 18-3中的类（VB.NET）。

代码清单 18-2 LanguageChanges\App_Code\Product.cs

public class Product
{
public int Id { get; set; }
public string Name { get; set; }
public decimal Price { get; set; }
}

代码清单 18-3 LanguageChanges\App_Code\Product.vb

Public Class Product
Private _Id As Integer
Public Property Id() As Integer
Get
Return _Id
End Get
Set(ByVal value As Integer)
_Id = value
End Set
End Property
Private _Name As String
Public Property Name() As String
Get
Return _Name
End Get
Set(ByVal value As String)
_Name = value
End Set
End Property
Private _Price As Decimal
Public Property Price() As Decimal
Get
Return _Price
End Get
Set(ByVal value As Decimal)
_Price = value
End Set
End Property
End Class

Product类包含3个公共属性（由于C#有自动属性的优势，因此C#示例采用自动属性进行定义，而VB.NET示例采用普通方式进行定义）。

现在，你需要创建一个Product类的实例，在.NET Framework 2.0中，采用以下方式（C#）：

Product product1 = new Product();
product1.Id = 1;
product1.Name = “Laptop Computer”;
product1.Price = 800.00m;

VB.NET采用以下方式：

Dim product1 As New Product()
product1.Id = 1
product1.Name = “Laptop Computer”
product1.Price = 800.0

注意，初始化一个简单的Product类使用了4行代码，这太浪费了。利用初始化器，这些工作可以用一行代码完成。用C#使用初始化器的代码如下：

Product product2 = new Product {Id=1, Name=”Laptop Computer”, Price=800.00m};

用VB.NET使用初始化器的代码如下：

Dim product2 As New Product() With {.Id = 1, .Name = “Laptop Computer”,.Price = 800.0}

在.NET Framework 2.0中，你可以声明Product类的构造函数，包含Id、Name和Price作为参数。但由于还需要在构造函数中将参数值赋给属性，因此导致了代码的膨胀。使用初始化器，你显然可以做类似的工作。并且，你还因此得到了好处：更加小巧的类，以及声明该类时使用的最少的代码。

理解类型推断

一个新特性使得C#和VB.NET看上去非常像JavaScript之类的动态语言，这个特性就是局部变量类型推断（Type Inference）。当使用类型推断时，你允许C#或VB.NET编译器在编译时确定变量类型。

下面的代码介绍了在C#中如何使用类型推断：

var message = “Hello World!”;

在VB.NET中，使用如下代码：

Dim message = “Hello World!”

注意，变量message在声明时并没有为其指定任何类型。C#和VB.NET编译器会根据你初始化变量时的值来推断变量的类型（这里为String类型）。

使用类型推断并没有性能上的损失（变量并非后期绑定）。编译器在编译时就判断出了变量的数据类型。

为了支持类型推断，C#引入了一个新的关键字：var。当你希望编译器自行判断变量的数据类型时，就可以使用var类型声明变量。

当你为局部变量提供初始值时才能使用类型推断。例如，下面的代码不会执行（C#）：

var message;

message = “Hello World!”;

由于message变量在声明时没有初始化，这段代码将不能通过编译（C#编译器）。

下面的代码在VB.NET中可以执行（但它做的并不是你想要的）：

Dim message

message = “Hello World!”

在这种情况下，VB.NET认为message变量为一个Object类型。由于将字符串赋给了变量，在运行时将会把变量的值转换为String类型。从性能角度看，这并不是一个好的做法。

注意：VB.NET 9.0中有一个新的Option叫做Option Infer。要想使隐含类型（implicit typing）正确工作，必须激活Option Infer。你可以在代码文件的最顶端加入“Option Infer On”来激活该类的Option Infer。

下一节将介绍类型推断与LINQ to SQL的关系。在使用LINQ to SQL时，很多情况下都无法确定变量的类型，因此你需要编译器能够进行推断。

理解匿名类型

另一个类似于动态语言中你可能比较熟悉的概念是匿名类型（Anonymous Types）。当你需要创建一个临时类型（type），却并不想创建一个类（class）时，可以使用匿名类型。

下面的代码介绍了如何在C#中创建匿名类型：

var customer = new {FirstName = “Stephen”, LastName = “Walther”};

在VB.NET中创建同样的匿名类型，可以使用下面的代码：

Dim customer = New With {.FirstName = “Stephen”, .LastName = “Walther”}

注意，customer变量并没有指定类型（这与JavaScript或VBScript非常类似）。尽管如此，customer仍然具有它的类型，你只是不知道它的名字而已：它是匿名的，理解这一点是十分重要的。

仅仅一行代码，我们既创建了一个新的类，又实例化了它的属性。其简洁性让我感动到内伤。

在使用LINQ to SQL时，匿名类型十分有用。因为你会发现你经常需要实时地（on the fly）创建一些新类型。例如，当执行一个查询时，你也许希望返回一个类，来代表一些数据库字段的集合。你将需要创建一个包含这些字段的临时类。

理解泛型

是的，我知道泛型（Generics）并不是.NET 3.5的新特性。但是，它对LINQ to SQL来说是相当重要的部分，值得我们花点篇幅来回顾。

注意：

要使用泛型，你需要引入System.Collections.Generic命名空间。

我使用泛型的绝大多数情况，是由于泛型集合。例如，如果想描述一个字符串列表，你可以这样声明（C#）：

List<string> stuffToBuy = new List<string>();

stuffToBuy.Add(“socks”);

stuffToBuy.Add(“beer”);

stuffToBuy.Add(“cigars”);

使用VB.NET，则这样声明：

Dim stuffToBuy As New List(Of String)

stuffToBuy.Add(“socks”)

stuffToBuy.Add(“beer”)

stuffToBuy.Add(“cigars”)

现在，利用集合初始化器，你可以仅用一行代码就声明一个强类型的字符串列表（C#）：

List<string> stuffToBuy2 = new List<string> {“socks”, “beer”, “cigars”};

注意：VB.NET并不支持集合或数组初始化器。

List类是泛型类，因为在声明的时候指定了它要包含的对象的类型。C#中，要在尖括号之间（< >）指定类型，而在VB.NET中要使用Of关键字。在上例中，我们创建了一个包含字符串的List类。同样地 ，我们也可以创建包含整型或其他自定义类型（如Product和Customer类，分别代表产品和顾客）的List类。

因为泛型是强类型的，因此泛型集合（如List）优于非泛型集合（如ArrayList）。ArrayList将所有对象都保存为object，而泛型将所有对象保存为它们特定的类型。当从ArrayList中取出一个对象时，在使用该对象前你必须将其转换为特定类型。而从泛型中取出对象则不需要这种转换。

泛型并不仅仅局限于集合。你可以创建泛型方法、泛型类以及泛型接口。

例如，当使用ADO.NET时，我喜欢将data reader转换为强类型的List集合。如Listing 18.4所示，GetListFromCommand()方法包含一个command对象，执行该对象，然后自动生成一个强类型的List。

代码清单 18-4 LanguageChanges\App_Code\GenericMethods.cs

using System;
using System.Collections.Generic;
using System.Data.SqlClient;
public class GenericMethods
{
public static List<T> GetListFromCommand<T>(SqlCommand command)
where T: ICreatable, new()
{
List<T> results = new List<T>();
using (command.Connection)
{
command.Connection.Open();
SqlDataReader reader = command.ExecuteReader();
while (reader.Read())
{
T newThing = new T();
newThing.Create(reader);
results.Add(newThing);
}
}
return results;
}
}
public interface ICreatable
{
void Create(SqlDataReader reader);
}

代码清单18-4中的GetListFromCommand()方法接收一个SqlCommand对象并且返回一个泛型List<T>。where子句用来约束泛型类型。泛型约束使得类型T必须实现ICreatable接口并且可以通过new实例化（准确的意思应为，必须包含无参的构造函数。——译者注）。

代码清单18-4中同样定义了ICreatable接口，它要求类实现Create()方法。

既然我们创建了可以将data reader 转换为强类型的list的泛型方法，那么我们就可以用它处理任何实现了ICreatable接口的类，如代码清单18-5中的Movie类。

代码清单 18-5 Movie.cs

using System;
using System.Data.SqlClient;
public class Movie : ICreatable
{
public int Id { get; set; }
public string Title { get; set; }
public void Create(SqlDataReader reader)
{
Id = (int)reader[“Id”];
Title = (string)reader[“Title”];
}
}

你可以通过下面的方法调用GetListFromCommand()方法（随书CD中的ShowGenericMethods.aspx页面使用了该代码）：

string conString = WebConfigurationManager.ConnectionStrings[“con”].ConnectionString;
SqlConnection con = new SqlConnection(conString);
SqlCommand cmd = new SqlCommand(“SELECT Id, Title FROM Movie”, con);
List<Movie> movies = GenericMethods.GetListFromCommand<Movie>(cmd);

在这里，泛型的出色之处在于，你不必为每个类型编写相同的代码将data reader 转换为泛型List。你只编写了一个泛型方法GetListFromCommand()，却可以用该方法转换任何复合泛型约束的类型。

理解泛型的正确方法是理解代码模板。你可以使用泛型来定义某一代码模式，而将一个特定的类应用与该模式中。

理解Lambda表达式

Lambda表达式是.NET Framework 3.5引入的另一个新特性，它提供了一种极其简洁的定义方法的方式。

假设你希望将Click事件处理器正确地绑定到button控件，代码清单18-6所示为其中一种方法。

代码清单 18-6 LanguageChanges\NormalMethod.aspx

<%@ Page Language=”C#” %>
<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Transitional//EN”
“http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd”>
<script runat=”server”>
void Page_Init()
{
btn.Click += new EventHandler(btn_Click);
}
void btn_Click(object sender, EventArgs e)
{
lblResult.Text = DateTime.Now.ToString();
}
</script>
<html xmlns=”http://www.w3.org/1999/xhtml”>
<head runat=”server”>
<title>Normal Method</title>
</head>
<body>
<form id=”form1” runat=”server”>
<div>
<asp:Button id=”btn” Text=”Go!” Runat=”server” />
<asp:Label id=”lblResult”  Runat=”server” />
</div>
</form>
</body>
</html>

在代码清单18-6中，Page_Init()方法将btn_Click()方法绑定到Button的Click事件。当点击按钮时，执行btn_Click()方法，显示当前日期和时间。这没什么特别之处。

.NET Framework 2.0引入了匿名方法的概念，其好处是可以声明内联方法。例如，代码清单18-7的功能与上例相同，所不同的是使用了匿名方法来处理Button的Click事件。

代码清单 18-7 LanguageChanges\AnonymousMethod.aspx

<%@ Page Language=”C#” %>
<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Transitional//EN”
“http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd”>
<script runat=”server”>
void Page_Init()
{
btn.Click += delegate(object sender, EventArgs e)
{
lblResult.Text = DateTime.Now.ToString();
};
}
</script>
<html xmlns=”http://www.w3.org/1999/xhtml”>
<head id=”Head1” runat=”server”>
<title>Anonymous Method</title>
</head>
<body>
<form id=”form1” runat=”server”>
<div>
<asp:Button id=”btn”Text=”Go!”Runat=”server” />
<asp:Label id=”lblResult”Runat=”server” />
</div>
</form>
</body>
</html>

在代码清单18-7中，处理Click事件的方法是在Page_Init()方法之中声明的。

注意：VB.NET并不支持匿名方法，但它支持Lambda表达式，所以VB.NET使用者请不要跳过。

Lambda表达式将匿名方法的概念更进一步，它将声明一个方法所必需的语法数量降到了最低。代码清单18-8使用了Lambda表达式，它功能与以上两个例子相同。

代码清单 18-8 LanguageChanges\LambdaExpression.aspx

<%@ Page Language=”C#” %>
<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Transitional//EN”
“http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd”>
<script runat=”server”>
void Page_Init()
{
btn.Click += (sender, e) => lblResult.Text = DateTime.Now.ToString();
}
</script>
<html xmlns=”http://www.w3.org/1999/xhtml”>
<head id=”Head1” runat=”server”>
<title>Lambda Expressions</title>
</head>
<body>
<form id=”form1” runat=”server”>
<div>
<asp:Button id=”btn”Text=”Go!”Runat=”server” />
<asp:Label id=”lblResult”Runat=”server” />
</div>
</form>
</body>
</html>

代码清单18-8中的Lambda表达式如下，

(sender, e) => lblResult.Text = DateTime.Now.ToString();

这仅仅是编写方法的简洁方式。Lambda表达式使用=>操作符（goes into操作符）来分隔方法的参数列表和方法体。编译器（通常）可以推断出参数的数据类型。尽管如此，如果你愿意，还是可以像下面的代码那样指明参数类型，

(object sender, EventArgs e) => lblResult.Text = DateTime.Now.ToString();

有必要提一下，当方法只有一个参数时，圆括号是可选的。因此，Lambda表达式可以非常简洁。

Visual Basic也支持Lambda表达式，但多了一些限制。Visual Basic中的Lambda表达式中只能包含表达式，不能包含语句。

VB中创建Lambda表达式的语法如下，

Dim AddNumbers = Function(x, y) x + y

Response.Write(AddNumbers(5, 6))

第一条语句创建了一个名为AddNumbers的变量，这即为一个Lambda表达式。VB语法Function(x, y) x + y相当于C#语法(x, y) => x + y。第二条语句使用两个参数调用Lambda表达式。

理解扩展方法

扩展方法的概念对于使用过JavaScript（考虑prototype）的人来说，也应该是非常熟悉的。

使用扩展方法，你可以向一个已有类中添加新的方法。例如，你可以创建任意一个方法，并将它添加到String类中。

由于害怕JavaScript注入攻击，我一直以来都对字符串进行HTML编码。在.NET Framework 2.0中，可以调用静态方法Server.HtmlEncode()来对字符串进行HTML编码，如下，

string evilString = “<script>alert(‘boom!’)<” + “/script>”;

ltlMessage.Text = Server.HtmlEncode(evilString);

在这段代码中，调用了Server类中的静态方法HtmlEncode()。如果我们可以向下面这样，直接调用字符串的HtmlEncode()方法，岂不妙哉

string evilString = “<script>alert(‘boom!’)<” + “/script>”;

ltlMessage.Text = evilString.HtmlEncode();

使用扩展方法，就可以这么做。我们可以向喜欢的类中添加任何方法。创建扩展方法，首先要创建一个静态类，并创建一个第一个参数为特殊参数的静态方法。代码清单18-9向String类中添加HtmlEncode()方法，以此描述了如何创建扩展方法。

代码清单 18-9 LanguageChanges\MyExtensions.vb[2]

public static class MyExtensions
{
public static string HtmlEncode(this string str)
{
return System.Web.HttpUtility.HtmlEncode(str);
}
}

注意，HtmlEncode()方法中仅有的参数前面多了关键字this。这样的参数指明了扩展方法所应用的类型。

在VB.NET中创建扩展方法与在C#中极为类似。代码清单18-10中的HtmlEncode()方法与上面的功能相同。

代码清单 18-10 LanguageChanges\MyExtensions.cs[3]

Imports System.Runtime.CompilerServices
Public Module MyExtensions
<Extension()> _
Public Function HtmlEncode(ByVal str As String) As String
Return System.Web.HttpUtility.HtmlEncode(str)
End Function
End Module

当使用VB.NET时，必须将扩展方法声明在一个module中。另外，还必须标记为System.Runtime.CompilerServices.Extension属性。

理解LINQ

终于，我们要讨论最后一个话题LINQ了，在这之后我们就可以开始研究本章的真正内容——LINQ to SQL了。

LINQ是Language Integrated Query的简称，它由C#和VB.NET的一系列新特性组成，这些特性允许我们执行查询。LINQ使得SQL查询就像C#或VB.NET的语法一样简单。

一个简单的LINQ查询示例如下，

var words = new List<string> {“zephyr”, “apple”, “azure”};

var results = from w in words

where w.Contains(“z”)

select w;

第一条语句创建了一个泛型列表words，它包含三个字符串。第二条语句就是LINQ查询。

LINQ查询及其像反向的SQL语句。它从列表中获得所有的包含字母z的单词。执行该查询，results变量将包含一下两个单词：

zephyr

azure

你可以对所有实现了IEnumerable<T>接口的对象执行标准的LINQ查询。这些实现了该接口的对象称为sequence。常用的sequence均为泛型List类或标准Array类（因此任何可以存入数组中的类，都可以使用LINQ进行查询）。

C#语言提供了以下子句，供我们在查询中使用：

• from——指定数据源以及用来迭代数据源的变量（范围变量）。
• where——过滤查询的结果。
• select——指定查询结果中的项。
• group——通过某一关键字，对相关的值进行聚合。
• into——存储聚合中的结果，或连接到一个临时变量。
• orderby——将查询结果按升序或降序进行排序。
• join——通过一个关键字，对两个数据源进行连接。
• let——创建一个临时变量，来存储子查询的结果。

创建一个LINQ查询，类似于创建一个反向的SQL查询。LINQ查询以一个from子句开始，它指定了数据的位置。然后，指定where子句来过滤数据。最后，指定用来表示数据的select子句（决定你要返回的对象和属性）。

在内部，标准LINQ查询被翻译成调用System.Linq.Enumerable类的方法。Enumerable类包含了一些扩展方法，这些扩展方法可以应用到任何实现了IEnumerable<T>接口的类中。

因此，查询

var results = from w in words

where w.Contains(“z”)

select w;

将被C#编译器翻译成下面的查询

var results = words.Where( w => w.Contains(“z”) ).Select( w => w );

第一个查询使用了查询语法（query syntax），第二个查询使用了方法语法（method syntax）。这两种查询是相同的。

注意，使用方法语法的查询在Where()和Select()方法中允许使用Lambda表达式。Where()方法中的Lambda表达式用来过滤数据，只返回包含字母z的单词。Select()方法指明要返回的对象和属性。如果我们将Lambda表达式w=>w.Length传递给Select()方法，该查询将返回每个单词的长度，而不是单词本身。

在创建LINQ查询时，使用查询语法还是方法语法纯粹属于个人偏好。查询语法属于语言的特性（C#或VB.NET），方法语法和语言无关。

我发现我使用方法语法的时候更多一些，因为查询语法不过是方法语法的子集。也就是说，使用方法语法可以做更多的事情。然而在某些情况下，使用方法语法编写查询会显得有些冗长。例如，使用查询语法编写LINQ to SQL左外连接，要比使用方法语法简单得多。

最后，选择方法语法还是查询语法其实并不重要，因为所有的查询语法语句都将被编译器翻译成方法语法。在使用标准LINQ时，这些调用的方法都存在与Enumerable类中。

在SDK文档中查找System.Linq.Enumerable类可以浏览Enumerable支持的全部方法。这里列举了一些有趣且实用的方法，

• Aggregate()——对序列中的每一项执行同一个函数。
• Average()——返回序列中每一项的平均值。
• Count()——返回序列的总项数。
• Distinct()——返回序列中不同的项。
• Max()——返回序列中的最大值。
• Min()——返回序列中的最小值。
• Select()——返回序列中的某些项或属性。
• Single()——返回序列中的某个单一值。
• Skip()——跳过序列中指定数目的项并返回剩下的元素。
• Take()——返回序列中指定数目的元素
• Where()——过滤序列中的元素。

本节我们讨论了标准LINQ（也叫LINQ to Objects）。LINQ使用了Provider Model，它有很多不同的实现，包括LINQ to SQL、LINQ to XML、LINQ over DataSets以及LINQ to Entities。LINQ也有很多第三方实现，包括LINQ to NHibernate和LINQ to SharePoint。这些不同的实现可以用来查询不同的数据源，如XML文件、SharePoint列表等等。

在本章，我们仅讨论LINQ to SQL，它是微软专门为操作数据库数据而设计的官方版本。下面就让我们开始吧。