昨天收到了华章寄来的新书《观止：微软创建NT和未来的夺命狂奔》，其实这本已经算不上是新书了，15年前英文版已经上市，而在15年之后终于有机会看到中文版。本来对这样一本书我是没有多大兴趣的，我一直认为这是一本歌颂微软有多么伟大、微软是多么有远见的书，但是当我读完前面几页的时候，发现我错了，这真的是一本绝佳的好书。微软NT从最初的计划的18个月，到实际的5年时间，这期间经历了怎样的故事？在NT团队中的大牛到底是些什么样的人物？我们无从知道，《观止：创建创建NT和未来的夺命狂奔》这本书详细记录了NT开发的全过程，从团队的组建到最终NT问世。

作者是一位《华尔街杂志》的著名记者，文笔犀利，用词泼辣，豪放不羁，微软NT团队的几十个人物，在作者的笔下栩栩如生，作者直言不讳写出的他们的缺点，甚至于相貌、家庭、婚恋、事业，大卫·卡特勒是其中的灵魂人物，他是一位计算机的天才，汇编高手，但他的性格很暴躁，脾气倔犟，这也许就是我们传说中的鬼才吧，看看书中对大卫·卡特勒的一段描述：

卡特勒骂人的功夫也炉火纯青。反复无常而且脾气倔犟，他可能根本不顾及脸面，大喊大叫，根本不顾及丧失最起码的礼貌。他发脾气时，嘴里动不动就冒出一连串污言秽语。每次新的爆发都把他的形象又磨砺一番。陌生人是最受不了的。有一次，一位女工程师在放满打印机的房间里第一次遇到卡特勒，卡特勒正在那里把卡在打印机里的碎纸往外抠。这位女工程师以期待的眼神看了卡特勒一眼，这时正好卡特勒也抬眼看见了她。于是，卡特勒咆哮起来了：“你就是那个把打印机搞垮的混蛋么？”

在昨天刚拿到书时，我并没有立即去看这本书，随手放在了桌边，晚上躺在床上顺手翻了一下，结果一发不可收拾，一直看到早晨5点多才睡觉，要不是顾及今天上班，估计我还会继续看下去。有人说在本书中仅看对卡特勒的描述就很值了，建议大家有空时也读读这本书，看看那些个性鲜明的人物他们的传奇故事，也许我们应该从中学到点什么。

评论: 94　查看评论　发表评论

最新新闻：
· Facebook与美国在线合作 整合AIM动态功能(2010-02-10 16:41)
· NDepend 3.0已与Visual Studio集成(2010-02-10 16:17)
· Ruby in Steel 1.5发布，去除IronRuby支持(2010-02-10 16:14)
· 淘宝网通过索引模式涉足网络文学(2010-02-10 15:59)
· 苹果发布 iPhone/iPad SDK 3.2 beta2 开发包(2010-02-10 15:37)

编辑推荐：Google Buzz相关新闻

网站导航：博客园首页  个人主页  新闻  闪存  小组  博问  社区  知识库

背景

在ASP.NET MVC中，HtmlHelper的扩展方法RenderPartial为我们使用UserControl带来了极大的方便，当我们指定一个UserControl时，RenderPartial会在当前View文件夹下查找相应的UserControl，如果没有找到则会到Shared文件夹下查找。然后在使用RenderPartial方法有一些性能方面的考虑，值得我们去关注。

设想有这样一个场景，一篇文章有很多个评论，在页面中我们需要呈现出一个评论列表，自然我们会定义一个评论的UserControl，如下代码所示：

Code 1:

<%@ Control Language="C#" Inherits="System.Web.Mvc.ViewUserControl<Comment>" %>
<%@ Import Namespace="TerryLee.MvcPerformance01.Models" %>
<p>
    ID: <%=Model.ID %> <br />
    Author: <%=Model.Author %> <br />
    Description: <%= Model.Description %>
</p>
<hr />

在页面中呈现评论列表，代码非常简单，仅仅是遍历所有的评论而已：

Code 2:

<div>
   <%
     foreach (var comment in Model.Comments)
     {
         Html.RenderPartial("CommentsItem", comment);
     }
  %> 
</div>

运行后效果如下，可以看到正确的输出了评论：

性能优化1

然而当我们同时输出200条评论的时候， 却要花费大量的时间，用Stopwatch来测量一下会发现，输出200条评论花费的时间基本在210ms左右，也就是说平均每条评论的输出花费了1ms。我们不妨看一下ASP.NET MVC的源代码，在WebFormViewEngine中当查找UserControl时，遵循如下查找模式：

Code 3:

public WebFormViewEngine() {
    MasterLocationFormats = new[] {
        "~/Views/{1}/{0}.master",
        "~/Views/Shared/{0}.master"
    };

    ViewLocationFormats = new[] {
        "~/Views/{1}/{0}.aspx",
        "~/Views/{1}/{0}.ascx",
        "~/Views/Shared/{0}.aspx",
        "~/Views/Shared/{0}.ascx"
    };

    PartialViewLocationFormats = ViewLocationFormats;
}

所以如果我们在RenderPartial方法中，指定了UserControl的完全路径，是不是可以避免这个查找过程呢？修改Code 2代码如下所示：

Code 4:

<div>
   <%
       foreach (var comment in Model.Comments)
       {
           Html.RenderPartial("~/Views/Shared/CommentsItem.ascx", comment);
       }
     %> 
</div>

现在再测试一下会发现呈现200条评论的时间平均值保持在10ms左右，比前面的方式提升了近200ms。然而我们是否真的找到了解决问题的方法？ASP.NET MVC难道不对查找的View路径进行缓存？带着这样的疑问，我们在ASP.NET MVC源代码VirtualPathProviderViewEngine的构造函数中，找到这样一段代码：

Code 5:

protected VirtualPathProviderViewEngine() {
    if (HttpContext.Current == null || HttpContext.Current.IsDebuggingEnabled) {
        ViewLocationCache = DefaultViewLocationCache.Null;
    }
    else {
        ViewLocationCache = new DefaultViewLocationCache();
    }
}

这里的判断说明如果启用了Debug模式，将会使用NullViewLocationCache，即不进行缓存，否则会使用DefaultViewLocationCache对View路径进行缓存。所以上面的测试结果都是基于Debug模式：

Code 6:

<compilation debug="true">

如果关闭了Debug模式，测试结果又该如何呢？使用下面代码关闭Debug模式：

Code 7:

<compilation debug="false">

再次进行测试，会发现使用Code 2代码呈现200条评论时，花费的时间平均值也是在10ms左右。所以在使用RenderPartial方法时，大可不必为了提升性能而指定UserControl的完全路径，ASP.NET MVC已经为我们做好了这一切，我们要做的仅仅是在发布到生产环境时，别忘了关闭Debug模式！在本示例中，开启Debug和关闭Debug模式在一次调用时的性能差距如下图所示：

性能优化2

现在回过头来看前面的代码，其实并没有做什么性能优化，仅仅时给大家提个醒而已。在Code 2中，我们的遍历代码放在了主页面中，即在每一次迭代中调用RenderPartial方法，尽管ASP.NET MVC在RenderPartial时，对于UserControl路径做了缓存，但是200次的调用仍然有不小的开销。如果我们的遍历代码放在UserControl中，而在主页面中只进行一次调用RenderPartial方法，结果又将如何呢？修改UserControl为下代码所示：

Code 8:

<%@ Control Language="C#" Inherits="System.Web.Mvc.ViewUserControl<IList<Comment>>" %>
<%@ Import Namespace="TerryLee.MvcPerformance01.Models" %>
<%
    foreach(Comment comment in Model)
    {
 %>
<p>
    ID: <%= comment.ID%> <br />
    Author: <%= comment.Author%> <br />
    Description: <%= comment.Description%>
</p>
<%} %>
<hr />

这样在主页面中，只进行一次RenderPartial调用，如下代码所示：

<div>
   <%
     Html.RenderPartial("CommentsItem", Model.Comments);
   %> 
</div>

此时再次测试，可以看到呈现200条评论所花费的时间不足1ms！为了直观期间，我们仍然使用图形表示如下：

从上图中可以看到，通过在UserControl中进行遍历，减少RenderPartial方法调用，带来的性能提升还是非常可观的。

总结

本文主要讨论在ASP.NET MVC中使用RenderPartial方法时的一些性能问题，记住两点：一是在ASP.NET MVC应用程序发布到生产服务器时，别忘了关闭Debug模式（对于ASP.NET WebForm应用程序也是一样）；二时尽可能的减少调用RenderPartial方法的次数，如通过在UserControl中进行遍历等方法。希望对大家有用。

评论: 106　查看评论　发表评论

最新新闻：
· Facebook与美国在线合作 整合AIM动态功能(2010-02-10 16:41)
· NDepend 3.0已与Visual Studio集成(2010-02-10 16:17)
· Ruby in Steel 1.5发布，去除IronRuby支持(2010-02-10 16:14)
· 淘宝网通过索引模式涉足网络文学(2010-02-10 15:59)
· 苹果发布 iPhone/iPad SDK 3.2 beta2 开发包(2010-02-10 15:37)

编辑推荐：Google Buzz相关新闻

网站导航：博客园首页  个人主页  新闻  闪存  小组  博问  社区  知识库

推荐序一

Silverlight是微软公司推出的新一代RIA技术，是一种跨浏览器、跨平台的.Net Framework的实现，用来构建和发布下一代的媒体体验和Web交互应用，它统一了服务器、Web和桌面的功能。作为一种新的Web内容载体，它可被以Web的方式来发布，在客户浏览器端运行时，它不但可以灵活地和各种服务器端应用交互，更具有和桌面体验一样的、丰富的图形渲染及用户交互控制能力。

Silverlight的意义还远不止于此。试想若干年前服务器端的情形，只有Raw HTML的发布功能，后来出现CGI，开始以构造程序的方式来处理Web请求发放响应，各种应用服务器支撑的编程模型逐步发展起来，直到现在像ASP.NET/WCF、J2EE这样的成熟框架，足以支撑起大规模的Web应用，其中最本质的一条发展线索就是编程模型在服务端的演进。现在，在Internet应用的客户端，具有类似的编程模型本质的线索，即将发展到一个新的阶段。从HTML的渲染、Form Data的原始回发，到Web2.0中对JavaScript、DOM技术的接近极致的应用，再到近一两年各种像Google Earth/FaceBook这类Web API的出现，似乎仍无法满足人们对Web应用用户体验的追求，开发者中的先锋们仍在寻求更先进的编程模型来支撑下一代Web应用的前端。RIA技术应用重新得到重视，借助新的内容类型来补充和突破HTML-Based的局限。然而，在Silverlight 之前，与其类似的技术均无法保证前台开发中“艺术”+“编程”这个Pair中“编程”的匹配度。前台编程模型，仍停留在“脚本”阶段，开发人员的先进思想及技巧、经验均无法“复用”过来，而且无法在保证客户端浏览器运行性能的前提下支撑复杂的桌面级别的UI逻辑和用户体验。现在Silverlight 2来了，它在UI渲染、艺术创作，以及UI逻辑、编程模型，双方面上带来了全新程度的提升。开发人员可以以面向对象面向组件的方式来开发、完整地复用以前的知识和经验。这是Silverlight在Web前台开发编程模型演进上所能带来的巨大变化，从这一点上，我们完全可以看到这项全新的RIA技术的前景。

那么，作为开发人员，我们如何尽可能快而又全面、准确地掌握Silverlight开发技术的方方面面呢？权威准确、翔实全面的资料，加以自己的学习与实践，以及先行者的分享与经验，这些都是不可缺少的。即使是一个非常有经验的.Net开发人员，在转入Silverlight开发时，有时也会由于对其中的异步操作、线程上下文理解不够深入而被莫名的问题弄得焦头烂额。所以，要在学习和实践中避免误区，少走弯路，学习先行者的经验是非常重要而有益的。

本书的作者TerryLee就是这样一位在Silverlight开发领域极富经验的先行者。

初识Terry，是读他博客园上的文章。他给我最深的印象是他的勤奋和才识。后来有缘成为同事，在公司的项目中一起工作，在几个开源项目中，他留给我最深的印象是他对软件技术的天赋。每当我向朋友介绍他时，总爱加上这样一句话：他是我遇到的仅有的几个在技术上最信得过的人之一，无论是系统架构设计方面还是代码实施动手能力方面。

Terry是一个热爱分享的人，这一点从他的博客上可以看出，更可以从与他日常的交流中感受到。这半年多来，Terry主要参与一个重量级应用Silverlight技术的项目，这个大型Web应用项目的页面全部采用Silverlight技术来实现。于是这段时间里与Terry聊到的技术话题中，Silverlight所占的比例就多出许多，经常会就一个可能的最佳实践进行“严正磋商”，或就Silverlight的一个Bug一起来“指点江山”；下面的场景更是常见：“ScottGu已经把我俩的那个问题转给Silverlight小组的Stefan了，估计马上会有答复了！”“Stefan的回复中提到这个问题可能与IAccessible接口有关，要不我来谈谈这个接口？”经常可以从他与Microsoft Silverlight小组的大量往来邮件中，得知一些来自“内部”的信息。不是每个人都能够像Terry这样与Silverlight有如此亲密接触的，即使你是这个方向上的MVP，我想，这与他的求知热情、热爱分享是分不开的。当然，每当回忆起这样的场景，我总会叮嘱他，一定不要忘记把这些都写入他的书中去！

《Silverlight 2完美征程》就是这样的一本书！在Silverlight 2 Beta1期间就已经成稿，在Silverlight 2 RTW版出来后，Terry又投入了大量的精力来重写和校正。书的内容覆盖了Silverlight 2开发的各个方面并被整理得井井有条，多年的技术写作功底在这里又一次得到了体现：图文并茂、讲解透彻，一如博客园中的TerryLee。

读过本书之后，我对Terry的第一句话就是，怎么还有这么多我们之前没有谈到的内容？

我相信，大家读后的收获，一定会比我更多！

曲春雨

资深架构师

2009年2月于北京

推荐序二

互联网，自从20世纪70年代进入人们的视线以来，经历了翻天覆地的变化。从保密的军事项目延伸到每个人都能享用的丰富服务，从简单的文字发布渠道发展到易于交互的富媒体媒介，从只能在工程师之间交流的复杂科技扩展到每个人都能触及的大众媒体，互联网的服务日益丰富，互联网的覆盖领域逐步扩大，互联网的使用人数迅猛增长。截至2009年1月，全球的网民人数已经达到了15亿，其中中国网民人数居全球第一，达到了2.98亿。

随着网民人数的不断增长，以及人们对互联网服务的巨大需求，互联网技术也在不断推陈出新，从而更好地满足人们的需求。微软的Silverlight技术自发布以来，受到了业内广泛的关注，Silverlight技术作为一种跨平台、跨浏览器的技术在丰富的媒体体验及丰富的交互式应用领域奉献给大家一个值得信赖的平台。

随着国内互联网领域对Silverlight技术应用的不断扩展，越来越多的开发者、设计师开始使用Silverlight技术来实现各种各样的Web应用，这里不乏国内知名的网站，如百度、腾讯、淘宝，等等。

作为一本国内互联网技术社区一直期待的的中文图书，《Silverlight 2完美征程》是一本不可多得的教材、工具书及参考书。本书分为4篇，它们分别为基础篇、进阶篇、高级篇及案例篇。作为一本源于实践的技术博客笔记，一本原汁原味的中文图书，《Silverlight 2完美征程》由浅入深，结合了大量的案例、注释及经验技巧，相信无论您是一个Silverlight技术的初学者还是已经将Silverlight应用于生产环境的开发者，在阅读本书的时候一定会受益良多。

最后，我强烈建议您经常访问本书作者——微软.NET及Web领域最有价值的专家李会军的技术博客http://www.cnblogs.com/TerryLee，相信从他的博客中您可以获得第一手的实战案例及开发技巧和经验。

黄继佳

微软（中国）有限公司 开发及平台合作部技术经理

2009年2月于北京

详情敬请访问《Silverlight 2完美征程》官方网站：http://www.dotneteye.cn/silverlight

评论: 82　查看评论　发表评论

最新新闻：
· Facebook与美国在线合作 整合AIM动态功能(2010-02-10 16:41)
· NDepend 3.0已与Visual Studio集成(2010-02-10 16:17)
· Ruby in Steel 1.5发布，去除IronRuby支持(2010-02-10 16:14)
· 淘宝网通过索引模式涉足网络文学(2010-02-10 15:59)
· 苹果发布 iPhone/iPad SDK 3.2 beta2 开发包(2010-02-10 15:37)

编辑推荐：Google Buzz相关新闻

网站导航：博客园首页  个人主页  新闻  闪存  小组  博问  社区  知识库

内容简介

本书详细介绍了微软下一代富互联网开发技术Silverlight，分为基础篇、进阶篇、高级篇和案例篇四个部分，共22个章节，以Silverlight 2为主要版本从不同的层面进行了阐释，第一部分介绍Silverlight 中的基础知识、控件模型以及它在绘图方面的能力；第二部分介绍了Silverlight中丰富的网络通信功能、托管代码与浏览器之间的互操作性以及数据绑定等；第三部分对Silverlight应用程序的生命周期进行剖析，并介绍了一些调试技巧；最后一部分开发了Deep Zoom应用程序和图表应用程序两个案例。全书对每个知识点都通过示例进行讲解，一步一步带您进入Silverlight世界。

详情敬请访问《Silverlight 2完美征程》官方网站：http://www.dotneteye.cn/silverlight

第一章 进入Silverlight世界

1.1 Silverlight概述

1.2 创建基本的Silverlight应用

1.3 开发工具简介

1.4 认识XAML

1.5 应用案例

1.6 本章小结

第二章 基本控件

2.1 控件模型概述

2.2 命令控件

2.3 文本编辑控件

2.4 选择控件

2.5 列表控件

2.6 日期控件

2.7 信息显示控件

2.8 数据显示控件

2.9 多媒体控件

2.10 布局控件

2.11 本章小结

第三章 界面布局

3.1 界面布局概览

3.2 使用Canvas绝对布局

3.3 使用StackPanel局部布局

3.4 使用Grid相对布局

3.5 使用边距

3.6 使用边框控件

3.7自定义布局面板

3.8 全屏支持

3.9 实例开发

3.10本章小结

第四章 封装控件观感

4.1 控件观感概览

4.2 使用样式

4.3 使用控件模板

4.4 视觉状态管理

4.5 本章小结

第五章 事件处理

5.1 事件概述

5.2 鼠标事件处理

5.3 键盘事件处理

5.4 焦点支持

5.5 实例开发

5.6 本章小结

第六章 绘图应用

6.1 绘图概览

6.2 直线Line

6.3 矩形Rectangle

6.4 椭圆形Ellipse

6.5 多边形Polygon

6.6 多线形Polyline

6.7 路径Path

6.8 实例开发

6.9 本章小结

第七章 画刷应用

7.1 画刷简介

7.2 单色实心画刷SolidColorBrush

7.3 线性渐变画刷LinearGradientBrush

7.4 放射性渐变画刷RadialGradientBrush

7.5 图像画刷ImageBrush

7.6 视频画刷VideoBrush

7.7 实例开发

7.8 本章小结

第八章 图像处理

8.1 图像处理简介

8.2 创建图像

8.3 图像拉伸

8.4 图像裁剪

8.5 半透明遮罩

8.6 实例开发

8.7 本章小结

第九章几何图形

9.1 几何图形介绍

9.2 几何图形的使用

9.3 简单几何图形

9.4 复杂几何图形

9.5 组合几何图形

9.6 本章小结

第十章 变形效果应用

10.1 变换对象简介

10.2 RotateTransform旋转变换

10.3 ScaleTransform缩放变换

10.4 SkewTransform倾斜变换

10.5 TranslateTransform移动变换

10.6 TransformGroup变换组

10.7 MatrixTransform矩阵变换

10.8 实现动画变换

10.9 动态添加变换

10.10 实例开发

10.11 本章小结

第十一章 数据绑定

11.1 数据绑定简介

11.2 绑定数据对象

11.3 数据绑定模式

11.4 绑定对象集合

11.5 构建数据服务

11.6 使用数据模板

11.7 DataGrid控件

11.8 数据转换

11.9 数据验证

11.10 实例开发

11.11 本章小结

第十二章 网络与通信

12.1 数据与通信概述

12.2 调用Web Service

12.3 调用WCF服务

12.4 使用WebClient通信

12.5 访问RESTful服务

12.6 使用HttpWebRequest通信

12.7 数据操作格式

12.8 访问ADO.NET Data Service

12.9 跨域通信策略

12.10 本章小结

第十三章 与浏览器交互

13.1 浏览器交互简介

13.2 访问文档对象模型

13.3 使用托管代码调用JavaScript

13.4 使用JavaScript调用托管代码

13.5 使用托管代码处理DOM元素事件

13.6 使用JavaScript处理托管事件

13.7 混合HTML和Silverlight

13.8 与浏览器交互相关辅助方法

13.9 安全设置

13.10 实例开发

13.11 本章小结

第十四章 影音播放

14.1 影音播放概述

14.2 MediaElement对象

14.3 媒体状态控制

14.4 VideoBrush和MediaElement

14.5 本章小结

第十五章 制作动画

15.1 动画概述

15.2 时间线

15.3 故事板

15.4 From/To/By动画

15.5 关键帧动画

15.6 编程方式控制动画

15.7 实例开发

15.8 本章小结

第十六章 自定义控件

16.1 控件模型

16.2 自定义简单按钮控件

16.3 本章小结

第十七章 独立存储

17.1 独立存储概述

17.2 使用独立存储

17.3 管理存储空间

17.4 读写应用程序配置

17.5 进一步认识独立存储

17.6 本章小结

第十八章 墨迹标注使用

18.1 InkPresenter控件使用

18.2 收集显示数据

18.3 笔画设计

18.4 美化InkPresenter

18.5 标注存储

18.6 本章小结

第十九章 应用程序剖析

19.1 应用程序概述

19.2 应用程序生命周期

19.3 应用程序宿主

19.4 应用程序包揭秘

19.5 应用程序部署

19.6 本章小结

第二十章 异常处理与调试

20.1 异常处理

20.2 使用Visual Studio基本调试

20.3 使用Windbg高级调试

20.4 本章小结

第二十一章 开发Deep Zoom应用程序

21.1 Deep Zoom概述

21.2 Deep Zoom示例

21.3 本章小结

第二十二章 开发图表应用程序

22.1 Silverlight Toolkit概述

22.2 开发图表示例

22.3 本章小结

详情敬请访问《Silverlight 2完美征程》官方网站：http://www.dotneteye.cn/silverlight

评论: 64　查看评论　发表评论

最新新闻：
· Facebook与美国在线合作 整合AIM动态功能(2010-02-10 16:41)
· NDepend 3.0已与Visual Studio集成(2010-02-10 16:17)
· Ruby in Steel 1.5发布，去除IronRuby支持(2010-02-10 16:14)
· 淘宝网通过索引模式涉足网络文学(2010-02-10 15:59)
· 苹果发布 iPhone/iPad SDK 3.2 beta2 开发包(2010-02-10 15:37)

编辑推荐：Google Buzz相关新闻

网站导航：博客园首页  个人主页  新闻  闪存  小组  博问  社区  知识库

概述

HttpApplication对象对于做ASP.NET开发的朋友，我想没有人不熟悉它。在ASP.NET开发中，经常避免不了要在HttpApplication中执行一些操作，如使用了ASP.NET MVC框架，就会在Application_Start 事件中避免不了这样的路由规则配置代码：

protected void Application_Start()
{
    RouteTable.Routes.IgnoreRoute("{resource}.axd/{*pathInfo}");

    RouteTable.Routes.MapRoute(
        "Default",                                              // Route name
        "{controller}/{action}/{id}",                           // URL with parameters
        new { controller = "Home", action = "Index", id = "" }  // Parameter defaults
    );
}

如果仅仅是这一条，看起来倒不觉的有什么问题，但如果同时在应用程序中使用了工作流，又避免不了在Application_Start出现启动工作流运行时的代码：

protected void Application_Start()
{
    // 注册路由规则
    RouteTable.Routes.IgnoreRoute("{resource}.axd/{*pathInfo}");
    RouteTable.Routes.MapRoute(
        "Default",                                              // Route name
        "{controller}/{action}/{id}",                           // URL with parameters
        new { controller = "Home", action = "Index", id = "" }  // Parameter defaults
    );

    // 启动工作流
    WorkflowRuntime workflowRuntime = new WorkflowRuntime("workflowServicesConfig");
    ExternalDataExchangeService externalDataExchangeService = new ExternalDataExchangeService();
    workflowRuntime.AddService(externalDataExchangeService);
    workflowRuntime.StartRuntime();
}

试想一下，现在我们仅仅是有了ASP.NET MVC路由规则的配置、WF运行时的启动，如果在应用程序中使用某种DI框架，如微软的Unity，是不是又避免不了要出现这样的容器初始化代码呢？

protected void Application_Start()
{
    // 注册路由规则
    RouteTable.Routes.IgnoreRoute("{resource}.axd/{*pathInfo}");
    RouteTable.Routes.MapRoute(
        "Default",                                              // Route name
        "{controller}/{action}/{id}",                           // URL with parameters
        new { controller = "Home", action = "Index", id = "" }  // Parameter defaults
    );

    // 启动工作流
    WorkflowRuntime workflowRuntime = new WorkflowRuntime("workflowServicesConfig");
    ExternalDataExchangeService externalDataExchangeService = new ExternalDataExchangeService();
    workflowRuntime.AddService(externalDataExchangeService);
    workflowRuntime.StartRuntime();

    // 初始化DI容器
    IContainerContext repositoryContainer = ContainerManager.GetContainer("repositoryContainer");
    repositoryContainer.Initialize();
}

再看看Application_Start事件中的代码，有ASP.NET MVC的工作，有WF的工作，也有Unity的工作，不知道将来还会有什么？这些原本互相之间没有任何联系的代码，现在却同时堆在了一起，当每一部分（或者说每一个框架）变化的时候，都会涉及到Application_Start中代码的修改，显然违反了OCP原则。那么有没有一种机制，让这些互不相干的模块之间互相独立，各自发生变化时不影响对HttpApplication？此时我们就需要对HttpApplication进行扩展，提供一个扩展点，让其他模块的程序附加到HttpApplication上面。

可扩展对象模式

我们知道WCF提供了非常完美的扩展机制，几乎在服务执行过程中的每一个环节上都提供有扩展点，如ServiceHostBase、OperationContext、InstanceContext、IContextChannel，这些对象都属于可扩展对象，它们都通过Extensions属性获取用于所有扩展的集合。我们能不能使用这种方式对HttpApplication也进行扩展呢，答案自然是肯定的。查阅一下MSDN就会知道在System.ServiceModel命名空间下面提供了这样的一组接口：IExtensibleObject、IExtension和IExtensionCollection，这是可扩展对象模式中最重要的三个接口，也只有这三个接口。

IExtensibleObject自然是定义了可扩展对象，即我们要对谁进行扩展，它的定义非常简单，仅仅是提供了一个只读的属性Extensions，用来提供所有扩展对象的集合，如下代码所示：

public interface IExtensibleObject<T> where T : IExtensibleObject<T>
{
    IExtensionCollection<T> Extensions { get; }
}

IExtension定义了扩展对象的契约，使对象可以通过聚合扩展另一个对象（此处的另一个对象，就是指上面所讲的扩展宿主IExtensibleObject），在IExtension中定义了两个非常重要的方法Attach和Detach方法，分别用来提供聚合或解聚的通知。

public interface IExtension<T> where T : IExtensibleObject<T>
{
    void Attach(T owner);
    void Detach(T owner);
}

当一个扩展对象IExtension附加到可扩展对象的扩展集合中时，它的Attach方法将会被调用；反之如果从集合中移除一个扩展对象时，它的Detach方法会被调用。这一点我们可以通过Reflector来得到验证，如下代码所示：

protected override void InsertItem(int index, IExtension<T> item)
{
    lock (base.SyncRoot)
    {
        item.Attach(this.owner);
        base.InsertItem(index, item);
    }
}

protected override void RemoveItem(int index)
{
    lock (base.SyncRoot)
    {
        base.Items[index].Detach(this.owner);
        base.RemoveItem(index);
    }
}

最后一个接口是IExtensionCollection，它是IExtension对象的集合。

对HttpApplication进行扩展

下面我们就看一下如何使用可扩展对象模式对HttpApplication进行扩展，首先定义可扩展对象，让ExtensibleHttpApplication派生于HttpApplication，并实现了IExtensibleObject接口，泛型的参数类型就是它自身，如下代码所示：

public class ExtensibleHttpApplication : HttpApplication,
    IExtensibleObject<ExtensibleHttpApplication>
{
    private IExtensionCollection<ExtensibleHttpApplication> _extensions;
    
    public ExtensibleHttpApplication()
    {
        this._extensions = new ExtensionCollection<ExtensibleHttpApplication>(this);
    }

    public IExtensionCollection<ExtensibleHttpApplication> Extensions
    {
        get
        {
            return this._extensions;
        }
    }
}

有了可扩展的HttpApplication之后，需要在HttpApplication中实现任何功能，都可以作为一个扩展附加到ExtensibleHttpApplication上去，如实现ASP.NET MVC路由，可以定义一个如下代码所示的扩展对象：

public class MvcHttpApplication : IExtension<ExtensibleHttpApplication>
{
    public void Attach(ExtensibleHttpApplication owner)
    {
        RouteTable.Routes.IgnoreRoute("{resource}.axd/{*pathInfo}");

        RouteTable.Routes.MapRoute(
            "Default",                                              // Route name
            "{controller}/{action}/{id}",                           // URL with parameters
            new { controller = "Home", action = "Index", id = "" }  // Parameter defaults
        );
    }

    public void Detach(ExtensibleHttpApplication owner)
    {
        //nothing
    }
}

同样如果要在HttpApplication中启动Workflow，可以再针对Workflow定义一个扩展对象，如下示例代码所示：

public class WorkflowHttpApplication : IExtension<ExtensibleHttpApplication>
{
    private WorkflowRuntime workflowRuntime;
    public void Attach(ExtensibleHttpApplication owner)
    {
        workflowRuntime = new WorkflowRuntime("workflowServicesConfig");
        ExternalDataExchangeService externalDataExchangeService = new ExternalDataExchangeService();
        workflowRuntime.AddService(externalDataExchangeService);
        workflowRuntime.StartRuntime();
    }

    public void Detach(ExtensibleHttpApplication owner)
    {
        workflowRuntime.StopRuntime();
    }
}

我们已经定义好了相应的扩展对象，只需要在相应的HttpApplication把扩展对象附加到ExtensibleHttpApplication上即可，修改Global.asax中的代码如下所示：

public class MvcApplication : ExtensibleHttpApplication
{
    protected void Application_Start()
    {
        this.Extensions.Add(new MvcHttpApplication());
        this.Extensions.Add(new WorkflowHttpApplication());
    }
}

现在代码是不是看起来优雅多了？现在如果要在Application_Start中，添加另外一些执行代码，只需要编写相应的扩展对象，并将其添加到Extension集合中即可。也许有朋友会问，这样每添加一些新的代码，还是要修改Application_Start中的代码啊？别忘了，可以通过配置可以解决这个问题，WCF中的扩展不也是可以采用配置方式实现，不是吗？同样，如果我们需要在Application_End事件中释放某些对象，可以直接从扩展集合中移除它，此时将会调用它的Detach方法。

总结

本文介绍了如何使用WCF中提供的可扩展对象模式扩展HttpApplication，事实上可扩展对象模式的作用远不在此，它可以扩展.NET类库中任何我们想对其进行扩展的对象，或者是一个自定义的类型，都可以使用可扩展对象模式对其进行扩展。

特别鸣谢：Jesse Qu

注1：由于TerryLee最近一段时间忙于别的事务，无暇顾及Blog，所以有大量的评论和E-mail都没能回复，请大家见谅。

注2：由TerryLee撰写的《Silverlight 2完美征程》一书，即将于本月底上市，敬请期待，详情大家可以访问本书官方网站http://www.dotneteye.cn/silverlight了解。

评论: 52　查看评论　发表评论

最新新闻：
· Facebook与美国在线合作 整合AIM动态功能(2010-02-10 16:41)
· NDepend 3.0已与Visual Studio集成(2010-02-10 16:17)
· Ruby in Steel 1.5发布，去除IronRuby支持(2010-02-10 16:14)
· 淘宝网通过索引模式涉足网络文学(2010-02-10 15:59)
· 苹果发布 iPhone/iPad SDK 3.2 beta2 开发包(2010-02-10 15:37)

编辑推荐：Google Buzz相关新闻

网站导航：博客园首页  个人主页  新闻  闪存  小组  博问  社区  知识库

继上次在园子里帮朋友发了一则招聘启事之后，还是原来的那个项目，朋友还需要一位测试工程师，全职兼职均可，不知道园子里有没有高手愿意加入？要求如下：

1.熟悉软件测试流程，至少2年以上的全职软件测试经验；
2.具备测试环境的搭建和维护能力；
3.具备独立完成测试工作的能力，编写测试计划、测试用例等；
4.具备熟练使用QTP、LoadRunner、VSTS等测试工具的能力；
5.具有良好的团队合作精神和敬业精神，热爱测试工作；
6.能够指导初级测试工程师的工作；
7.09年2、3月份具有充足的时间参与该项目
8.全职兼职均可
9.薪水：全职参与薪水应不低于8000元/月，兼职根据参与时间面谈。

有意者请将简历发至lovenets@sina.com或者lovenets@hotmail.com

评论: 33　查看评论　发表评论

最新新闻：
· Facebook与美国在线合作 整合AIM动态功能(2010-02-10 16:41)
· NDepend 3.0已与Visual Studio集成(2010-02-10 16:17)
· Ruby in Steel 1.5发布，去除IronRuby支持(2010-02-10 16:14)
· 淘宝网通过索引模式涉足网络文学(2010-02-10 15:59)
· 苹果发布 iPhone/iPad SDK 3.2 beta2 开发包(2010-02-10 15:37)

编辑推荐：Google Buzz相关新闻

网站导航：博客园首页  个人主页  新闻  闪存  小组  博问  社区  知识库

起因

近日不断看到有关“LINQ已死”，“LINQ玩完了吧”的言论，甚至于更有牛人说出“程序开发最终会回到本机代码上”，暂不说这些言论是否正确，且先来看看各位的惊人言论，下面仅摘录部分：

言论1

言论2

言论3

言论4

言论5

以上言论，我仅摘取了部分，其实通过这些，我只想说几个问题：

请认清事实真相

首先根本没有“LINQ已死”的说法，也没有“LINQ to SQL已死”的说法，关于“LINQ已死”的言论完全来自于社区，而起因则是ADO.NET团队的一篇《Update on LINQ to SQL and LINQ to Entities Roadmap》，文章最后说到

于是社区中就猜测微软将会放弃LINQ to SQL，请注意，ADO.NET团队只是说推荐使用ADO.NET Entity Framework，将会加大对它的投入，而并没有没有什么“废弃”言论，“已死”更无从谈起！退一步讲，就算微软不再开发LINQ to SQL，这跟LINQ又有何关系呢？LINQ to SQL只是LINQ家族中众多Providers中的一个而已，没了LINQ to SQL，不是还有LINQ to Object、LINQ to XML、LINQ to Entities的吗？况且LINQ to SQL还没死，它也不会死，作为一个轻量级的ORM框架，LINQ to SQL在中小项目以及快速开发中的优势还是非常明显的，这一点，如果你没有用过LINQ to SQL，就不要再说它是多么多么的垃圾！

投入小不等于放弃，就算微软不再开发LINQ to SQL，LINQ to SQL现在的功能已经能够大部分开发的需要，再加上它灵活的可扩展性，完全可以通过自定义一些扩展来满足自己开发的需要。

再强调一遍：请停止“LINQ已死”或者“LINQ to SQL已死”的荒谬言论吧！

请区分清概念

作为“专业的开发人员”，请在了解了某个技术之后，再对其发表见解吧，最起码你得知道这个技术是怎么回事吧？如别人说“LINQ to SQL已死”，然后就有人跟着说“幸好我没用LINQ”，这又关LINQ啥事了。博客园老赵曾经在6月份写过一篇文章《觉得有必要来澄清几组重要概念》，其中介绍了LINQ以及LINQ to SQL的区别，但是很遗憾，社区中不能正确区分LINQ和LINQ to SQL的朋友太多了，看到这些言论，让我们为老赵这篇文章默哀一分钟吧。

再强调一遍：LINQ to SQL只是LINQ家族中众多Providers中的一个而已，这是真的，请不要怀疑，不要把LINQ等同于LINQ to SQL，如果觉的LINQ to SQL字母太多了，可以使用L2S来代替，但请不要使用LINQ来代替LINQ to SQL。

请收起LINQ无用论

“LINQ很垃圾”，“拒绝LINQ”，看到这些，真的有些悲哀，LINQ仅仅是一个语言特性，它能够让我们在编写代码时使用内置的查询语法对于数据集合进行操作，提高我们的开发效率，仅此而已。当然如果你的数据集合来源不同，会对应不同的Providers。既然拒绝LINQ，为何不干脆连泛型、数组以及.NET Framework中内置的基础类库等等一起拒绝，甚至于拒绝C#语言，而回到所谓的“本机代码”上去呢，直接编写二进制的“01101100”程序是不是比C#语言更方便，更快速？如果是，请原谅，我错了，我道歉。

再强调一遍：LINQ仅仅是一个语言特性而已，请收起LINQ无用论。

后记

写下本篇文章，其实不是想针对某个人，只是看到大家都在误解LINQ，甚至有些初学者因为看到“LINQ已死”的谬论，都不敢去学习，去使用了。所以忍不住站出来说几句话，如有得罪您的地方，请见谅！

相关文章：

微软决定废弃两个框架

评论: 318　查看评论　发表评论

最新新闻：
· Facebook与美国在线合作 整合AIM动态功能(2010-02-10 16:41)
· NDepend 3.0已与Visual Studio集成(2010-02-10 16:17)
· Ruby in Steel 1.5发布，去除IronRuby支持(2010-02-10 16:14)
· 淘宝网通过索引模式涉足网络文学(2010-02-10 15:59)
· 苹果发布 iPhone/iPad SDK 3.2 beta2 开发包(2010-02-10 15:37)

编辑推荐：Google Buzz相关新闻

网站导航：博客园首页  个人主页  新闻  闪存  小组  博问  社区  知识库

最近有朋友接到一个项目，是为杂志社开发一套内部办公系统，09年3月底交活，准备用ASP.NET MVC + WF开发，想从咱们园子里找2-3名高手加盟开发，待遇每人月应不会低于8,000元，要求如下：
1. 09年2、3月份有充足的时间参与开发，最好这两个月能专职于本项目；
2. 对待分配给自己的工作认真负责；
3. 有2年以上ASP.NET开发经验，熟悉ASP.NET3.5+SP1的新特性；
4. 已熟练掌握ASP.NET MVC的开发；
5. 熟悉LINQ，以及ADO.NET Entity Framework；
6. 最好具有WF的开发经验；
7. 09年2、3月份人在北京；
8. 有时需要加班工作。

有意者请将简历发至lovenets@sina.com或者lovenets@hotmail.com

评论: 59　查看评论　发表评论

最新新闻：
· Facebook与美国在线合作 整合AIM动态功能(2010-02-10 16:41)
· NDepend 3.0已与Visual Studio集成(2010-02-10 16:17)
· Ruby in Steel 1.5发布，去除IronRuby支持(2010-02-10 16:14)
· 淘宝网通过索引模式涉足网络文学(2010-02-10 15:59)
· 苹果发布 iPhone/iPad SDK 3.2 beta2 开发包(2010-02-10 15:37)

编辑推荐：Google Buzz相关新闻

网站导航：博客园首页  个人主页  新闻  闪存  小组  博问  社区  知识库

在10月份Anytao同学推荐了Jurgen Appelo整理的Top 100 Blogs 第三季度版本，现在Jurgen Appelo又整理出了第四季度开发者的Top 100 Blogs，其中有些Blogger的排名发生了变化，退出了前100名，而又很多新的Blogger当选，再次推荐给大家。

大家可以从这里下载OPML文件，直接导入自己的RSS阅读器。

原文链接：Top 100 Blogs for Developers (Q4 2008)

评论: 39　查看评论　发表评论

最新新闻：
· Facebook与美国在线合作 整合AIM动态功能(2010-02-10 16:41)
· NDepend 3.0已与Visual Studio集成(2010-02-10 16:17)
· Ruby in Steel 1.5发布，去除IronRuby支持(2010-02-10 16:14)
· 淘宝网通过索引模式涉足网络文学(2010-02-10 15:59)
· 苹果发布 iPhone/iPad SDK 3.2 beta2 开发包(2010-02-10 15:37)

编辑推荐：Google Buzz相关新闻

网站导航：博客园首页  个人主页  新闻  闪存  小组  博问  社区  知识库

微软模式与实践小组最近发布了应用程序架构指导袖珍版本，总共有6本，分别介绍了不同类型应用程序的架构指导，包括敏捷架构方法、Mobile应用程序、RIA应用程序、富客户端应用程序、Web应用程序以及Service架构等，非常值得一看。

1. 敏捷架构方法

下载指导

2. Web引用架构

下载指导

3. 移动应用架构

下载指导

4. RIA架构

下载指导

5. 富客户端架构

下载指导

6. 服务架构

下载指导

评论: 35　查看评论　发表评论

最新新闻：
· Facebook与美国在线合作 整合AIM动态功能(2010-02-10 16:41)
· NDepend 3.0已与Visual Studio集成(2010-02-10 16:17)
· Ruby in Steel 1.5发布，去除IronRuby支持(2010-02-10 16:14)
· 淘宝网通过索引模式涉足网络文学(2010-02-10 15:59)
· 苹果发布 iPhone/iPad SDK 3.2 beta2 开发包(2010-02-10 15:37)

编辑推荐：Google Buzz相关新闻

网站导航：博客园首页  个人主页  新闻  闪存  小组  博问  社区  知识库