MVC最佳实践资料汇集

原文链接：http://space.itpub.net/740297/viewspace-586997

1.创建UrlHelper类的扩展方法，生成相对路径URL

请避免将控制器、行为、或者路由名称作为字符串到处传递，创建UrlHelper的扩展方法来封装它们，例如：

1.public static class UrlHelperExtension  

2.{  

3.    public static string Home(this UrlHelper helper)  

4.    {  

5.        return helper.Content("~/");  

6.    }  

7.  

8.    public static string SignUp(this UrlHelper helper)  

9.    {  

10.        return helper.RouteUrl("Signup");  

11.    }  

12.  

13.    public static string Dashboard(this UrlHelper helper)  

14.    {  

15.        return Dashboard(helper, StoryListTab.Unread);  

16.    }  

17.  

18.    public static string Dashboard(this UrlHelper helper, StoryListTab tab)  

19.    {  

20.        return Dashboard(helper, tab, OrderBy.CreatedAtDescending, 1);  

21.    }  

22.  

23.    public static string Dashboard(this UrlHelper helper, StoryListTab tab, OrderBy orderBy, int page)  

24.    {  

25.        return helper.RouteUrl("Dashboard", new { tab = tab.ToString(), rderBy = orderBy.ToString(), page });  

26.    }  

27.  

28.    public static string Update(this UrlHelper helper)  

29.    {  

30.        return helper.RouteUrl("Update");  

31.    }  

32.  

33.    public static string Submit(this UrlHelper helper)  

34.    {  

35.        return helper.RouteUrl("Submit");  

36.    }  

37.}  

这样的话，您就可以在视图中这样来使用：

1.<a href="<%= Url.Dashboard() %>">Dashboard</a>  

2.<a href="<%= Url.Profile() %>">Profile</a>  

而不是这样:

1.<%= Html.ActionLink("Dashboard", "Dashboard", "Story") %>  

2.<a href="<%= Url.RouteUrl("Profile")%>">Profile</a>  

并且在控制器中我能这么用：

1.return Redirect(Url.Dashboard(StoryListTab.Favorite, OrderBy.CreatedAtAscending, 1))  

而不是这样:

1.return RedirectToAction("Dashboard", "Story", new { tab = StoryListTab.Favorite, rderBy = OrderBy.CreatedAtAscending, page = 1 }); 

原文链接：http://www.cnblogs.com/CareySon/archive/2009/10/31/1593731.html

上一周我我在罗马进行了两场对于开发完成不久的http://www.dotnetromacesta.org/的Asp.net MVC的演讲。而其中一场演讲内容是关于我对于Asp.net MVC最佳实践的看法.因为这场演讲是在意大利进行的，为了大家能更好的阅读，我将演讲所用的ppt翻译成英文。

   原文链接：http://sexywp.com/mvc-best-practice.htm  

关于Controller的最佳实践

1-删除AccountController

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

2-隔离外部网络和Controller

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

3-使用一个IOC容器

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

4-和“神奇的strings”说不

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

    神奇的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标签“中.

前一段日子，写了一篇《MVC就是一个选择题》，重点描述了我对MVC模式的迷惑。随着我对这个模式应用时间的深入，渐渐感到得心应手，这个模式早在30多年前就已经发明了，确实经受了时间的考验，可以说是千锤百炼。但是，实践过程中，我也发现，更多的时候照猫画虎还是有很多弊端的，想要真正做好MVC的选择题，必须在项目中不断犯错误，不断修正，才能逐渐走上正轨。我参加的项目主要运用了Yii框架，是目前比较流行的一个Web开发框架。随着前不久，1.1.6版本的发布，我发现Yii框架的文档中，多了一篇MVC最佳实践的文章。我想，这个文章对于初学者来说，应该具备相当的指导性，而且指导相当具体。如果也有跟我相同的迷茫，应该好好钻研一下这篇文章，并且身体力行去验证之，这里给出链接。我在这篇文章中，就是概括简述一下那篇文档的内容。

MVC的核心理念是代码的重用和关注点的分离（Separation of concern 我个人对这个理解就是将数据和表现进行分离）。如何正确遵循MVC的原理来编写代码是有一些基本指导原则可以遵循的。为了便于理解后面将要叙述的指导原则，我们这里认为一个典型的Web应用由以下几个子应用（部分）组成：

• 前端——网站界面，面向普通用户
• 后台——一部分有管理权限的用户用于维护Web应用的正常运转
• 控制台——在终端中执行的命令，或者是定时任务如cronjob，用于日常运维
• API——用于第三方合作，或者二次开发

Model

模型用于表示底层数据结构，经常在整个应用的不同部分共享，有些模型在前后台、API中都会用到，所以一个模型应该遵循的指导原则有：

• 包含属性用于描述特定的数据
• 应该包含业务逻辑，以确保数据能够满足表现的需要
• 应该包含数据操作的代码，比如数据存储、检索
• 不应该使用$_GET $_POST这样的只有在前端才会出现的数组，在控制台和API用到时候，可能就无法复用了
• 不应该出现HTML代码，负责表现的代码应该放到view文件中

在上述指导原则下，可能会写出非常庞大的Model类（过多数据操作，业务逻辑代码包含其中）。这种情况下，建议进一步抽象，提炼出一个基类，包含最通用的功能，然后前端、后端和API在用到时候，将各个子应用才相关的逻辑放到基类继承出来的子类里面。

View

视图主要就用于前端表现的代码。

• 包含HTML，以及所有负责表现的代码，可以出现PHP，但是只用于遍历数据、格式化数据
• 不应该包含DB请求
• 不应该出现引用$_GET $_POST这类数组的代码，这应该是Controller的工作。View只是专注于表现，布局等和页面呈现有关的业务，用户的请求数据应该由Controller和Model负责处理
• 如果必要，可以访问Model和Controller的属性，不过这是为了满足表现的需要

可以使用诸如布局、部分视图、HTML Helper类、Widget等框架特性来最大程度重用View的代码。

Controller

控制器是将模型、视图和其他组件组装在一起形成一个应用的粘合剂。控制器直接负责处理终端用户的请求。

• 可以访问$_GET $_POST这样的用户请求数组
• 创建模型，并决定一个模型对象的生命周期
• 不应该出现SQL语句，数据库请求应该放到Model中
• 不应该出现HTML代码，而应该将其放入到View中

在一个设计良好的MVC应用中，控制器是非常轻量级的，经常只有几十行代码的样子；而Model总是非常复杂而且庞大，包含了所有的用于表现的数据及其操作方法。这是因为由数据结构和业务逻辑组成的模型对每个应用来说，都是独特的，需要大量的定制化工作来满足应用的需求；控制器的逻辑经常遵循一个特定的套路，在各个应用中都差不多，因此可以被框架底层代码极大程度地简化（也就是说不是控制器代码少，而是Web开发框架已经都抽象出来并且都帮你做好了，这也就是框架的价值和能够实现快速开发的原因）。