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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Conclusion
小结

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

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

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

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

参考文献

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

简介

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

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

压缩算法描述

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

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

图1 - 整数压缩算法

解压缩算法描述

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

解压缩算法参考实现

EOF.

参考文献

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

范畴

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

术语

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

正文

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

翻译如下：

具体计算方法参见图1。

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

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

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

参考实现

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

EOF.

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

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

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

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

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

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

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

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

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

小结

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

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

[新闻]关于 Silverlight 2 Control Tookit 的最新消息
博客园首页 社区 新闻频道 小组 博问 网摘 闪存]]>http://www.cnblogs.com/AndersLiu/archive/2008/07/27/asp-net-mvc-tip-13-unit-test-your-custom-routes.htmlAnders LiuAnders LiuSun, 27 Jul 2008 03:36:00 GMThttp://www.cnblogs.com/AndersLiu/archive/2008/07/27/asp-net-mvc-tip-13-unit-test-your-custom-routes.htmlhttp://www.cnblogs.com/AndersLiu/comments/1252374.htmlhttp://www.cnblogs.com/AndersLiu/archive/2008/07/27/asp-net-mvc-tip-13-unit-test-your-custom-routes.html#Feedback3http://www.cnblogs.com/AndersLiu/comments/commentRss/1252374.htmlhttp://www.cnblogs.com/AndersLiu/services/trackbacks/1252374.html[翻译] ASP.NET MVC Tip #13 – 对自定义路由进行单元测试

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

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

创建路由表

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

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

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

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

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

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

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

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

• /archive/12-25-1966

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

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

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

以此类推。

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

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

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

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

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

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

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

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

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

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

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

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

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

小结

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

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

[新闻]新编程语言——微软的“M”语言
博客园首页 社区 新闻频道 小组 博问 网摘 闪存]]>http://www.cnblogs.com/AndersLiu/archive/2008/07/26/AJAX-Panels-with-ASPNET-MVC.htmlAnders LiuAnders LiuSat, 26 Jul 2008 01:00:00 GMThttp://www.cnblogs.com/AndersLiu/archive/2008/07/26/AJAX-Panels-with-ASPNET-MVC.htmlhttp://www.cnblogs.com/AndersLiu/comments/1251891.htmlhttp://www.cnblogs.com/AndersLiu/archive/2008/07/26/AJAX-Panels-with-ASPNET-MVC.html#Feedback8http://www.cnblogs.com/AndersLiu/comments/commentRss/1251891.htmlhttp://www.cnblogs.com/AndersLiu/services/trackbacks/1251891.htmlAJAX Panels with ASP.NET MVC

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

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

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

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

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

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

MVC AJAX给你转机

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

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

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

使用Ajax.Form方法

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

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

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

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

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

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

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

看看结果吧！

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

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

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

[新闻]Firefox 3.1 Beta
博客园首页 社区 新闻频道 小组 博问 网摘 闪存]]>http://www.cnblogs.com/AndersLiu/archive/2008/07/26/asp-net-mvc-tip-12-faking-the-controller-context.htmlAnders LiuAnders LiuFri, 25 Jul 2008 23:39:00 GMThttp://www.cnblogs.com/AndersLiu/archive/2008/07/26/asp-net-mvc-tip-12-faking-the-controller-context.htmlhttp://www.cnblogs.com/AndersLiu/comments/1251881.htmlhttp://www.cnblogs.com/AndersLiu/archive/2008/07/26/asp-net-mvc-tip-12-faking-the-controller-context.html#Feedback1http://www.cnblogs.com/AndersLiu/comments/commentRss/1251881.htmlhttp://www.cnblogs.com/AndersLiu/services/trackbacks/1251881.htmlASP.NET MVC Tip #12 – 仿制控制器上下文

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

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

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

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

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

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

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

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

Mocking VS Stubbing

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

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

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

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

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

创建仿制控制器上下文

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

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

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

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

测试表单参数

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

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

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

测试查询字符串参数

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

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

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

测试用户

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

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

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

测试用户角色

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

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

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

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

测试浏览器Cookies

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

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

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

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

测试会话状态

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

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

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

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

小结

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