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

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

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

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

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

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

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

/Product/34

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

/Product/Update/34

/Product/Delete/34

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

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

/Product/New

/Product/Create

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

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

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

/Product/Create

/Product/Edit/1

/Product/Destroy/1

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

/Product/Insert

/Product/Update/1

/Product/Delete/1

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

------

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

ASP.NET MVC CodePlex Preview 4 Release Notes

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

简介

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

What’s New

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

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

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

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

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

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

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

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

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

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

输出缓存过滤器

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

ASP.NET AJAX的变化

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

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

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

路由的命名空间

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

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

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

TempData的增强可测试性接口

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

ActionInvoker可扩展改进

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

ViewDataDictionary

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

MVC的未来

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

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

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

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

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

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

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

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

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

已知问题

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

摘要：在这个Tip中，Stephen Walther解释了当控制器action需要返回一个特定的视图时，应该如何进行单元测试。他建议你如果打算建立单元测试的话，还是要明确地指出视图的名称。

ASP.NET MVC框架是一个高度可测试的框架。你可以很方便地测试MVC控制器Action，确定它是否能够返回你所期望的结果。在这个Tip中，我会向你展示如何测试一个会返回特定视图的控制器action。

考虑清单1中名为HomeController的MVC控制器。该控制器包含一个名为Index()的action。Index() action返回一个视图。然而，这里并没有提供视图的名字。视图的名字是通过控制器action的名字推断出来的。因此，当你到用Index() action时，会返回名为Index的视图。

HomeController还包含另外一个名为Index2()的action。这个action也返回一个视图。然而，这个action明确地指出了视图的名字。视图的名字被传递到View()方法中。该控制器action和第一个控制器action做的事情是相同的。然而，第一个控制器action的视图名字是推断出来的，而第二个控制器action的视图名字是明确指定的。

清单1 - HomeController.cs

 1using System;
 2using System.Collections.Generic;
 3using System.Linq;
 4using System.Web;
 5using System.Web.Mvc;
 6 
 7namespace Tip3.Controllers
 8{
 9    public class HomeController : Controller
10    {
11        public ActionResult Index()
12        {
13            return View(); // view name inferred
14        }
15 
16        public ActionResult Index2()
17        {
18            return View("Index"); // view name explicit
19        }
20 
21    
22    }
23}

如果你计划为ASP.NET MVC应用程序创建单元测试，则你必需明确指定视图的名字。否则，即便返回了正确的视图，也无法通过单元测试。

清单2的测试类中包含了两个测试方法。第一个方法测试了HomeController的Index() action，第二个方法测试了Index2()。第一个测试总是失败，而第二个测试则能成功（参见图1）。

清单2 - HomeControllerTest.cs

 1using System;
 2using System.Collections.Generic;
 3using System.Linq;
 4using System.Text;
 5using System.Web.Mvc;
 6using Microsoft.VisualStudio.TestTools.UnitTesting;
 7using Tip3;
 8using Tip3.Controllers;
 9 
10namespace Tip3Tests.Controllers
11{
12    /**//// <summary>
13    /// Summary description for HomeControllerTest
14    /// </summary>
15    [TestClass]
16    public class HomeControllerTest
17    {
18        [TestMethod]
19        public void Index()
20        {
21            // Arrange
22            HomeController controller = new HomeController();
23 
24            // Act
25            ViewResult result = controller.Index() as ViewResult;
26 
27            // Assert
28            Assert.AreEqual("Index", result.ViewName);
29        }
30 
31 
32        [TestMethod]
33        public void Index2()
34        {
35            // Arrange
36            HomeController controller = new HomeController();
37 
38            // Act
39            ViewResult result = controller.Index2() as ViewResult;
40 
41            // Assert
42            Assert.AreEqual("Index", result.ViewName);
43        }
44 
45 
46    }
47}

图1 - 单元测试结果

单元测试无法推断视图名字。我的建议是，如果打算进行单元测试，应该总是明确指定视图的名字。

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

------

广告：欢迎光临[.NET正则表达式库] http://regex-lib.net/。