[转]ASP.NET MVC 4 最佳实践宝典

原文：http://www.cnblogs.com/sonykings/archive/2013/05/30/3107531.html

ASP.NET MVC最佳实践

本文档提供了一套旨在帮助创建最佳优化ASP.NET MVC应用程序的 开发人员编码准则。 当然，由您来选择这些优化准则。

模型的建议

Model是定义业务领域相关的对象，应该包含业务逻辑（对象如何动作和关联），验证逻辑（验证对象的有效值），数据逻辑（数据对象如何持久化），和会话逻辑（跟踪用户状态）。

创建独立的Model项目，在ASP.NET MVC 项目中引用Model程序集。

尽量将频繁复用的业务逻辑放置在Model中。

如将所有业务逻辑放置在Model项目中，可根据实际业务数据来生成View和Controller。有如下好处：

     1.减少重复的业务逻辑。

     2.在View中减少业务逻辑，View易于理解。

     3.业务逻辑的测试仅仅和Model有关。

例如，下面需要显示用户的用户名 – 先显示Last Name，在View中代码如下：

<% if (String.Compare((string)TempData["displayLastNameFirst"], "on") == 0) { %> Welcome, <%= Model.lastName%>, <%= Model.firstName%> <% } else { %> Welcome, <%= Model.firstName%> <%= Model.lastName%> <% } %>

然而你需要在每一个地方重复这一逻辑。如将这一业务逻辑放置在Model中，可在Model中添加一个属性封装这一逻辑。

public string combinedName { get { return (displayLastNameFirst ? lastName + " " + firstName : firstName + " " + lastName); } private set { ; } }

 

这样，可大大简化视图代码：

<% Welcome, <%= Model.combinedName %> %>

将所有验证逻辑放置在Model中

所有输入验证应该在Model层，包括Client-side 验证。

可使用ModelState 添加验证检查，代码如下所示：

if (String.IsNullOrEmpty(userName))

{

ModelState.AddModelError("username", Resources.SignUp.UserNameError);

}

不过，更好的办法是使用 System.ComponentModel.DataAnnotations，在Model类的属性上添加attribute，如下所示：

public class User

{

[Required(ErrorMessageResourceName = "nameRequired", ErrorMessageResourceType = typeof(Resources.User))]

public String userName { get; set; }

...

}

为数据访问定义接口

接口用来暴露数据访问类的方法，强化ASP.NET MVC 的松散耦合设计。

可考虑使用Entity Framework 或 LINQ to SQL 创建对数据库的访问类，Entity Framework 和 LINQ to SQL 都支持存储过程。

将所有会话逻辑放置在Model中。

它已超出本文档在模型中存储会话状态的各种机制深入探讨的范围。 作为一个起步的点下面是几个可能性的会话状态存储：

技术	优势	弱点
在过程中	没有所需额外的安装程序。	如果 web 站点需要扩展，起作用。
会话状态服务	轻量 sertvice 在 web 场中的每台计算机上运行。 更快地数据库会话存储。	如果该服务出现故障，会话数据将丢失。
数据库	会话数据保持不变。	会话状态较慢。 管理成本也较高。

视图建议

View用来展示Model数据，Controller负责选择View。业务逻辑不属于View，Model负责业务逻辑。View非常灵活，如Model的View可通过HTML显示，同样的Model也可通过XML 视图来呈现。

将HTML放置在View和Partial View中（不要在Controller中）

默认的ASP.NET视图引擎提供了如下视图文件：HTML View（.aspx），Partial HTML View（.ascx）和Master page（.master）

如下视图演示了对partial view的调用：

<%@ Page Title="" Language="C#" MasterPageFile="~/Views/Shared/Site.Master" Inherits="System.Web.Mvc.ViewPage" %>

…

Below is a list of items submitted by <b>

<%= Html.Encode(ViewData["name"]) %></b>.

<p>

...

<div id="items">

<% Html.RenderPartial("ItemsByName");%>

</div>

</asp:content>

Partial view（ItemsByName.ascx）如下所示：

<%@ Control Language="C#" %>

…

<% foreach (Seller.Controllers.Items item in (IEnumerable)ViewData.Model)

{ %>

<tr>

<td>

<%= Html.Encode(item.title)%>

</td>

<td>

<%= Html.Encode(item.price)%>

</td>

</tr>

<% } %>

</table>

<% } %>

Partial View 是一个强大的扩展和重用机制。你可在不同的地方包含相同的View，不必编写重复的代码。

在View中使用ViewData访问数据

ASP.NET 提供了如下机制在View模板中访问数据：

ViewData.Model 对象 – 在Controller的action方法中，在return语句中传入一个Model对象（return View(myModelObject)）。

ViewData Dictionary – 在action方法中存入数据（ViewData[“key”] = value），接着在View中方法相同的dictionary。

在可能的情况下，应该是一ViewData Model，而不是ViewData 来访问数据，因为Model 提供了类型安全。此外，你应在View模板中，使用数据访问机制，而不是Request / Session 来访问。

如需要显示一个对象的多个属性，可使用ViewData.Model，并创建一个强类型View。针对seller详细页面，seller类有name、phone、address、email等等属性，在呈现View之前，你可在Controller中对ViewData.Model 赋值seller对象实例。但是如果是一些零散的数据，如page#、用户名和current time，则一般使用ViewData字典。

在使用模型绑定（Model bingding）时，避免在view中访问数据。

在Controller 中访问数据库，在执行View之前，将从数据库中检索的数据复制给轻量的View Model对象，这样，轻量的View Model对象不必在视图执行时检索数据。

使用（自动生成）客户端验证

从ASP.NET MVC 2 开始，可以很容易添加客户端验证。

(1) 如前所述，在Model层中添加数据验证逻辑；

(2) 确保项目中Scripts目录有如下javascript 文件：MicrosoftAjax.js 和 MicrosoftMvcValidation.js；

(3) 在表单提交页面，添加如下代码：

<script src="<%= Url.Content("~/Scripts/MicrosoftAjax.js") %>" type="text/javascript"></script>

<script src="<%= Url.Content("~/Scripts/MicrosoftMvcValidation.js") %>" type="text/javascript"></script>

(4) 在表单中添加如下代码：

<% Html.EnableClientValidation(); %>

现在如果编辑表单内容，当输入值不合格时，客户端马上进行验证提醒。

在模板中插入server-side 注释

在View模板中使用服务端注释，在HTML呈现时，会剔除。

如下是server-side注释：

<%-- This is a server side template comment --%>

不要在View模板中使用HTML 注释，因为这些注释会呈现在web浏览器中，可被用户看到。

使用HTMLHelper 扩展方法。

System.Web.Mvc.Html 类中包含了很多有用的HTML 扩展方法。

Form 表单生成（BeginForm）

输入字段生成（checkbox、hidden、radio button、textbox）

链接URL生成（ActionLink）

XSS保护（Encode）

尽可能使用这些HTML扩展方法，如下是使用route table创建一个链接：

<%= Html.ActionLink(“Home page”, “Default”) %>

控制器的建议

Controller 和指定的Action方法由路由系统根据匹配的URL规则调用。Controller 接收路由系统的输入参数，包括HTTP 请求上下文（Session、Cookies、Browser等等）。

使用Model Binding，而不是手动解析请求。

ASP.NET MVC 通过Model binding 抽象了许多对象反序列代码，Model binding机制是将Request Context数据通过反射对应到Action方法中定义的对象类型上。

如下代码是Seller类，定义了表单提交的数据：

[csharp] public class Seller { public Int64 ID { get; set; }

             public string Name { get; set; }

             public string Phone { get; set; }

             public string Address { get; set; } }

[/csharp]

如下的是Register View 表单：

[html] < % using (Html.BeginForm())

{ %> < legend>Account Information</legend>

< p> < %= Html.TextBox(“Name”) %> < /p>

< p> < %= Html.TextBox(“Phone”) %> < /p>

< p> < %= Html.TextBox(“Address”) %> < /p>

< p> < input value=”Register” /> < /p> < % } %>

[/html]

Controller 需要Register Action 方法，提供Model binding：

[csharp] public ActionResult Register([Bind(Exclude="ID")] Seller newSeller) { … } [/csharp]

默认的model binder 会寻找类中的每一个属性，以Name 为例：

(1) 先查找Request.Form[“Name”]； (2) 接着RouteData.Value[“Name”]； (3) 接着 Request.QueryString[“Name”]； (4) 最后如没有匹配，则为null；

从Register action方法可以看到，通过默认的model binder，对象属性将被赋值。Model binding系统也会进行验证逻辑，如data annotations attributes。

Model binding系统有丰富的扩展机制，可对object的创建、赋值和验证进行全面定制。

在Action方法中显示命名View。

在action方法中完成必要逻辑后，最后返回ViewResult 或 PartialViewResult对象。如不传入View名称给result 类，View 文件将默认为action 名称。如一个名为Products的Controller，有一个List 的Action方法，在List action方法调用 return View() 方法，且不传入任何参数。MVC 框架将寻找 /Views/Products/List.aspx 视图，如不存在，则继续寻找 /Views/Products/List.ascx。如仍不存在，则尝试 /Views/Shared/List.aspx和/Views/Shared/List.ascx。你可使用/Views/Shared 存放多个Controllers共享的视图。

为了避免混淆，在action方法中，显式命名View，如 return View(“explictViewName”)，这样可从不同的Action调用List视图。

在提交表单时使用Post/Redirect/Get（PRG）

根据HTTP POST 和 GET 的定义：

• HTTP GET 用于不更改Model数据；
• HTTP POST 用于更改Model 数据；

下面是一个清晰的描述，在post back的action方法接收表单数据，返回 RedirectToAction(<actionName>)，该方法导致一个HTTP 302 （临时跳转），并对<actionName>方法生成GET请求，这就是Post – Redirect – Get 模式。

传统的ASP.NET 表单回传数据，有可能导致数据的重复提交，可通过MVC Post-Redirect-Get模式解决这一问题。

但是，这一模式会造成client-side性能影响，因为redirect跳转会再次请求服务器，需要在性能成本和可用性之间进行判断。

实现HandleUnknownAction 和 HandleError

默认的unknown action响应是404（Not found）错误。可在Controller中重载HandleUnknownAction，针对这一错误实现一个默认视图。此外，可在controller的action方法添加HandleError属性，针对未捕获异常提供标准的错误视图。

路由的建议

ASP.NET MVC 中路由映射 URL 直接到controller，而不是一个特定的文件。默认的路由添加到RouteTable，在Global.ascx文件的Application_Start中定义。该路由表负责映射特定URL到Controller和Action。

当时使用标准路由时，从特定的路由到一般路由进行排序。

路由表是有序的，因此按特定的到一般规则来创建路由。举一个示例，假定你有一个product category需要创建URL：

* http://sellmyproducts/                             * http://sellmyproducts/Page# * http://sellmyproducts/category * http://sellmyproducts/category/Page#

假定List方法定义如下（在ProductsController 类中）： Public ViewResult List(string category, int page)

基于之前指定的URL，下面的路由规范将正确路由用户到正确的视图：

[csharp] routes.MapRoute(null,“”,

new { controller = “Products”, action = “List”, category = (string)null, page = 1 }

);

routes.MapRoute(

null,

“Page{page}”,

new { controller = “Products”, action = “List”, category = (string)null },

new { page = @”d+” }

);

routes.MapRoute(

null,

“{category}”,

new { controller = “Products”, action = “List”, page = 1}

);

routes.MapRoute(

null,

“{category}/Page{page}”,

new { controller = “Products”, action = “List”},

new { page = @”d+” }

); [/csharp]

使用命名的路由机制，避免路由歧义

在使用ASP.NET 路由机制时，必须知道路由机制是如何工作的。否则，会浪费很多时间去跟踪错误的路由。有一个办法是显式命名路由，可缓解这一问题。

如下路由映射定义了命名路由： [csharp] routes.MapRoute(“Default”,“”,

new { controller = “Products”, action = “List”, category = (string)null, page = 1 }

);

routes.MapRoute(

“PageRoute”,

“Page{page}”,

new { controller = “Products”, action = “List”, category = (string)null },

new { page = @”d+” }

); [/csharp]

使用这些路由定义，可创建PageRoute路由链接：

[html] < %= Html.RouteLink(“Next”, “PageRoute”, new RouteValueDictionary( new { page = i + 1 } )); %> [/html]

可扩展性的建议

在ASP.NET MVC 框架中有很多点可扩展，可替换任何核心组件，下面列举了部分：

• routing engine (MvcRouteHandler)
• controller factory (IControllerFactory)
• view engine (IViewEngine)

例如，你可以重写自己的Controller factory，使用IoC容器。另外，你可通过添加定制的行为来扩展框架，在框架中有一些标准的过滤器（filter），如OutputCache、HandleError和Authorize等等。

使用过滤器来添加动作

MVC支持通过attribute添加动作（filter），可在action方法和action结果之前和之后。这些过滤器在请求处理管道允许进行轻量级扩展。

过滤器可应用在action方法上，更改其行为。另外，过滤器也可应用在controller类之上，对controller类中的所有action方法生效。可使用基类base class定义通用的行为方法，并应用过滤器在基类controller上，接着确保其他controller继承该基类。

如你想增加一个功能，记录每一次请求信息，分析HTTP header的问题。如下代码定义了一个继承ActionFilterAttribute的类： [csharp] public class LogHeadersFilterAttribute : ActionFilterAttribute { public override void OnActionExecuting(ActionExecutingContext filterContext) { foreach (string header in filterContext.HttpContext.Request.Headers.AllKeys) { Debug.WriteLine(“Header ” + header); Debug.WriteLine(“Value ” + filterContext.HttpContext.Request.Headers.Get(header)); } base.OnActionExecuting(filterContext); } } [/csharp] 为了添加给filter到指定的action方法，可简单将LogHeaderFilter属性添加到Action（或Controller）上面。

可测试性建议

MVC模式的一个主要优点是加强可测试性，保持关注点分离。在ASP.NET MVC 应用程序的Model中，可清晰分离和测试业务逻辑。如你可测试向拍卖网站增加一条拍卖纪录，不必依赖Controller或View。

编写单元测试

ASP.NET MVC 提供了很多工具，开发人员可用来创建可测试的应用程序。此外，也相当比较简单添加第三方的单元测试框架、Mocking框架、或依赖注入容器。ASP.NET MVC 提供了灵活的架构方便单元测试。

 

安全建议

安全是现代软件开发项目中一个很重要的方面。尽管没有框架提供完美的安全，但有很多地方可做，来保护ASP.NET MVC 应用程序。

安全保护以防攻击

网站安全需要考虑所有web开发人员编写的企业级网站和服务，有许多众所周知的工具，如下所示：

• Cross-site scripting (XSS) attacks
• SQL injection
• Cross-site Request Forgery (XSRF)
• Improperly implementing model binding

(1) 阻止跨站攻击（XSS）：

• 使用ValidateInput 属性禁止无效的请求；
• 在所有显示用户输入数据的地方使用Html.Encode，不管是立即呈现或数据将存入数据库，然后显示；
• 在Cookies上设置HttpOnly标识，阻止Javascript读取和发送Cookies；

(2) 阻止SQL注入攻击：

• 总是使用参数化SQL查询；
• 不要传递未经检验的SQL脚本到数据库；
• 使用ORM工具，如Entity Framework，可完全消除在应用程序代码中编写SQL语句；

(3) 阻止跨站请求伪造攻击：

• 在表单中使用Html.AntiForgeryToken 类阻止跨站伪造情况。在接收post请求的Action方法上设置ValidateAntiForgeryToken 属性；

(4) 正确实现model binding：

• 显式指定模型绑定的类成员名称，如[Bind(Include=显式属性名称)]；
• 还可创建视图模型（View model），用来接收外部表单输入，视图模型仅包含外部输入的属性；

对用户进行验证和授权保护内容

对于受限的数据视图，通过编写自定义的RoleProvider，或使用Authorize 过滤器属性。

使用<%: %> (.NET 4) 保护，以防XSS攻击

在.NET 4.0 之前，开发人员通过使用如下代码，来确保编码HTML：

<%= Html.Encode(ViewData["name"]) %>

上述代码以防 XSS (cross-site scripting) 攻击。

如果你使用.NET 4，可不必使用上面的语法，简化语法如下：

<%: ViewData["name"] %>

该脚本会自动对字符串进行HTML编码（如有必要）。

本地化和全球化建议

全球化是产品多语言化的进程，本地化是使全球化的产品适应特定的语言和国家。为了开发支持全球化和本地化的web应用程序，至少需要知道一点：不要在View视图中使用硬编码的字符串。

使用ASP.NET 特殊resource文件夹和resource文件

在编写ASP.NET 应用程序时，添加App_GlobalResources存放全球化内容，App_LocalResources存放本地化内容。在这些目录中，根据Controller名称添加资源文件（.resx）。也就是说，如Controller命名为SubmissionPipeline，资源文件应该命名为SubmissionPipeline.resx。

Visual Studio转换这一文本映射类为全局类，可按如下方式调用：

Resources.<resource_filename>.<string_name>

接着在View视图中调用：

<%= Resources.SubmissionPipeline.continueButton %>

当翻译的资源文件存在，每一个资源文件使用如下格式命名：

<filename>.<language>.resx.

如德国版本的资源文件，命名为：SubmissionPipeline.de.resx

性能的建议

网站的性能问题是多方面的，每一个瓶颈都会影响性能：

(1) 数据库

• 低效率查询；
• 错误的索引；
• 非范式设计；

(2) 带宽问题

• 大的文件请求（受单个大的图片文件、CSS / js / html 等等）；
• 引用许多其他的资源，如多个script、CSS、或图片文件；
• 慢的连接速度；

(3) 处理能力

• Server： 费时费力的操作；
• Client：低性能的javascript文件；

下面将仅仅关注服务器的处理和请求大小。

考虑使用AJAX的局部页面更新，减小带宽的使用。

缓和服务器处理和请求大小性能问题的一种方法是使用AJAX做局部页面更新。ASP.NET MVC 内置支持AJAX，有助于简化这一模式。性能的改进得益于该模式减少了请求的数量和HTML 片段的大小。

下面示例演示如何使用AJAX 实现局部页面更新：

(1) 选择想更新的HTML局部，并标明ID；

<div> to be updated dynamically </div>

(2) 添加javascript文件，启用AJAX（一般存放在master视图中）；

<script src=”<%= Url.Content(“~/Scripts/MicrosoftAjax.js”) %>” type=”text/javascript”></script>

<script src=”<%= Url.Content(“~/Scripts/MicrosoftMvcAjax.js”) %>”></script>

(3) 在想更新的View视图中，添加AJAX链接，引用action方法（范例中action方法命名为RetrieveItems）；

<%= Ajax.ActionLink(“Refresh All”, “RetrieveItems”, new { criteria = “all” } , new AjaxOptions { UpdateTargetId = “items” })%>

(4) 实现Controller的action方法，返回Partial 视图；

不要过度使用Session，可使用TempData作为短期存储空间。

在创建web网站时，尝试将对象添加的Session对象中，让对象可用。问题是将这些对象存放在Session中，可导致Server 不得不存放额外的信息，然而这些信息仅仅在页面跳转时有用。正确的方法是将这些页面跳转的临时数据存放在TempData字典中。

假设从POST请求中接收数据，action方法处理POST 过程如下： [csharp] [AcceptVerbs(HttpVerbs.Post)] public ActionResult LogIn(Seller person) { … TempData["name"] = person.Name; return RedirectToAction(“ItemUpload”); } [/csharp] 在上面的示例中，在跳转到ItemUpload action方法之前，seller的名称已存放到TempData 字典中。在ItemUpload action方法中，可从TempData 字典中获取seller的名称，并进一步存放到ViewData字典中，可在View视图中方法。 [csharp] public ActionResult ItemUpload() { string name = TempData["name"] as string; ViewData["name"] = name; return View(); } [/csharp] 对静态页面使用OutputCache 过滤器

对返回的、比较少更新的数据，可使用OutputCache 属性；可应用在首页。可针对HTML和JSON数据类型使用这一技术。在使用OutputCache时，仅需指定缓存名称，不必指定其他内容。如需要更佳调整cache设置，可使用Web.config 文件的output cache部分。

如下所示，OutputCache attribute应用于Dashboard action方法： [csharp] [AcceptVerbs(HttpVerbs.Get), OutputCache(CacheProfile = "Dashboard")] public ActionResult Dashboard(string userName, StoryListTab tab, OrderBy orderBy, int? page) { … } [/csharp] 在Web.config文件中，设置缓存时间为15秒。

考虑针对长运行请求使用异步controller。

ASP.NET 线程池默认针对每一个CPU有12同时工作线程的限制。当请求数超过server处理这些请求的能力时，这些请求将放置在队列中。如每一个请求都需要大量的时间等待外部的资源，如数据库或大文件操作。在整个等待期间，这些外部请求将阻塞线程。当请求队列很长时（5000个请求等待），server将开始想要503错误（server too busy）。

在ASP.NET 4，同时工作线程默认为5000，可以提高默认的限制。有一个好的办法是让长运行时间的请求异步进行，ASP.NET MVC 支持实现异步controller来实现这一目的。

十二个ASP.NET MVC实践

可以帮助大家更好的进行开发工作。希望对大家有所帮助。

关于Controller的最佳实践

1-删除AccountController

让Demo代码在你的程序中是一个非常不好的做法。请永远不要使用AccountController。

2-隔离外部网络和Controller

如果依赖HttpContext，数据访问类，配置，日志等，则会让程序难以测试，修改或者进一步开发。

3-使用一个IOC容器

使达到第二条最佳实践更加容易，使用IOC容器管理所有外部依赖我使用 Ninject v2，这种IOC容器有很多，如果需要的话，你甚至可以自己实现一个。

4-和“神奇的strings”说不

永远不要使用ViewData[“key”]，而要为每一个视图创建一个ViewModel,从而使用强类型的ViewPage。

神奇的Strings是很邪恶的，因为你可能由于错误的拼写而导致视图出错,而强类型的Model不仅可以有智能感知，而且错误是在编译时获取而不是在运行时。

5-创建你自己的“个人惯例”

使用Asp。net MVC作为你个人（或者公司）的参考构架的基础，你还可以使Controller和View继承于你自己的基类而不是默认的基类来让你的惯例更加透彻。

6-注意Verbs

就算不使用最合适的HTTP Verb,最要也要采用PRG模式，(Post-Redirect-Get):使用Get来显示数据，使用Post来修改数据。

关于Model的最佳实践

7–DomainModel != ViewModel

DomainModel代表着相应的域，但ViewModel却是为View的需要而创建。这两者之间或许(一般情况下都)是不同的，此外DomainModel是数据加上行为的组合体，是由复杂的变量类型组成的并且具有层次。而ViewModel只是由一些String等简单变量类型组成。如果想移除冗余并且容易导致出错的ORM代码,可以使用AutoMapper。如果想要了解更多，我推荐阅读：ASP。NET MVC View Model Patterns。

8-为“共享”的数据使用ActionFilter

这是我自己的解决方案，或许需要在未来发帖继续探讨。通常情况下，你都不希望你的Controller获取的数据在几个不同的View之间共享，我的方法则是使用ActionFilter来获取在几个不同View之间共享的数据，然后用合适的View来显示。

关于View的最佳实践

9-不要使用CodeBehind模式

永远不要。

10-尽可能的写HTML代码

我认为Web开发人员必须的习惯于写HTML(或者CSS和JAVASCRIPT)。所以最好少用仅仅用来隐藏HTML代码的HTMLHelper（比如HTML。Submit或者HTML。Button）。这也是我会在未来的帖子里讨论的。

11-如果有if语句，使用HTMLHelper

View必须是哑巴（Controller是瘦子而Model是胖子）,如果你发现自己在使用if语句，那就写一个HTMLHelper来隐藏选择条件语句。

12-仔细的选择你的View引擎

默认的引擎室WebFormViewEngine，IMHO并不是最好的引擎，我更倾向于选择Spark ViewEngine,因为对于我来说这个引擎更适合MVC的View。我喜欢的是“dominates the flow and that code should fit seamlessly”对于每一次循环来说IF语句都会被定义在”HTML标签“中。

附录：未来软件发展6大趋势

<非常简短好记！>

一。胖客户瘦服务端

二。操作系统是个网页

三。MVC+REST控制器优化架构

四。RIA富客户方案

五。嵌入插件式风格

六。HTML5---6