[翻译] ASP.NET MVC Tip #11 – 使用标准的控制器操作名称

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

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

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

操作 示例URL 说明
Details /Product/Details/5 显示一个单独的资源如一条数据库记录。例如，显示Id为5的一个单独的Product。
Index /Product/Index 显示一组资源。例如，显示数据库里产品表中的所有产品。
Create /Product/Create 显示用于创建一个新资源的表单。例如，显示一个用于创建新产品的表单。
Insert /Product/Insert 将一个新资源插入数据库。通常，在完成一次插入后你应该重定向到其它操作。
Edit /Product/Edit/5 显示用于编辑一个现有资源的表单。例如，显示一个用于编辑Id为5的产品的表单。
Update /Product/Update/5 更新数据库中的现有资源。通常，在完成一次更新后你应该重定向到其它操作。
Destroy /Product/Destroy/5 显示一个页面，确认是否真的希望从数据库中删除一个资源。
Delete /Product/Delete/5 从数据库中删除一个资源。通常，在完成一次删除后你应该重定向到其它操作。
Login /Home/Login 显示一个登录表单。
Logout /Home/Logout 注销一个用户。通常，在完成一次注销后你应该重定向到其它操作。
Authenticate /Home/Authenticate 验证一对用户名和密码。通常，在完成一次验证后你应该重定向到其它操作。

我的这些操作名字（非常粗略）是基于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能够作为你开发一款命名约定的起点。