原文作者：scottgu关于ASP.NET MVC Framework的一套介绍：
译注：以上链接全部换为博客堂scottgu博客中文版链接，并比原文增加了第四部分的链接。
Scott Hanselman的一段很酷的视频教程Screencast。
概述
MVC （模式-视图-控制器）是一套开发ui为中心应用程序中很流行的模式。他建立在一个简单的概念上：把整个应用分割成三个逻辑模块
- Model,模式
- View,视图
- Controller.控制器
ASP.NET MVC Framework是mvc模式的一套实现，并且内置了开发web应用的能力。让我们快速浏览一下这三个模块。
图一：MVC Framework
- Model: 是你程序的领域逻辑。通常来说，model的状态会存储在数据库里。在开发一个n层应用程序中，他是介于领域模型和商业逻辑之间的中间层。
- View: 典型的用户界面，他负责把model的数据展示给用户，并且接受用户输入。
- Controller: 处理用户的动作。他是整个ASP.NET MVC Framework的终极驱动力量。建立在用户动作之上，他决定了使用怎样的方法到model里取得数据，把这些数据组织成view data并且最终决定使用什么样的View去展示这些数据。
跟web form模型相比，ASP.NET MVC Framework是一套更棒的开发web应用程序的方法。他给我们提供了一下能力：
- 清晰的分层思路，一个模块专注于处理一类问题。并且在开发过程中给了我们绝佳的TDD (测试驱动开发) 体验。在单元测试中我们完全不用顾及其他模块，因为在framework中绝大多数的模块都是interface-based的所以这就允许我们为他们创建模仿对象。
- 整个framework都是非常容易扩展的。可以在不影响其他模块的前提下轻松替换或者自定义每一个模块。
- Pretty/SEO (搜索引擎优化) URLs. URLs的设置和创建权牢牢的掌握在我们手里。跟URL重写彻底说再见吧。
- 真正的无状态网页。我们再也不需要处理postbacks和ViewState了。
- 玩去控制HTML代码产生。这意味着再也没有多余的标签了。
- 可以利用现有的ASP.NET的一些特性，比如Providers, Caching, Configuration等等。
译注：我主要还是喜欢clean url和clean html。
请求流程
在asp.net web form程序中，URLs经常被映射到物理磁盘上的文件。当请求一个url时，于该文件相关的代码将被执行。但是，在ASP.NET MVC Framework中，URLs在Controllers就结束了，而不是传统的物理文件。Routing Handler把URL映射到Controller。当应用程序启动时，他需要注册URL筛选规则。当请求来临时，Routing Handler使用这些规则把请求映射到controller。让我们来快速浏览一下在ASP.NET MVC Framework中请求在不同层之间的流转过程：
图二：The Request Flow
- 用户请求了一个URL.
- ASP.NET MVC Framework在已经注册的筛选规则中寻找请求的URL所匹配的Controller.Framework把这个请求交给匹配的Controller
- Controller调用Model来创建ViewData。在ViewData的创建过程中可能会多次调用model。
- Model前面提到过他是一个中间层。他也许是一个数据存取模块，工作流，依赖于外部的web service等等。Model把Controller请求的数据返回给他。.
- Controller选择一个View并且把他刚从model里得到的数据发送给View。View展现这些数据，并且生成html给用户浏览。
默认约定
在下一步开发之前，我们必须先知道下面一些默认的约定。
首先，当为进来的请求匹配Controller时，framework使用类似UrlPathController 这样的模式来匹配。例如，如果请求的是 http://www.example.com/Home，那么就要使用HomeController 来处理这个请求。一旦当请求到达Controller，Controller根据子路径来执行一个指定的行为。或者，如果路径中没有行为那么就执行默认的行为。Controller 的默认行为是在application start事件中和筛选规则定义时一起定义的。行为在Controller类中定义为方法。例如，如果请求以下地址http://www.example.com/Home/Index，那么就会自动执行HomeController中的Index方法。如果url中还有子路径，那么就会把子路径中每个部分转换成方法的参数。
其次，当使用Visual Studio建立ASP.NET MVC项目时，会自动建立Controllers, Models和Views这三个文件夹。推荐在对应的文件夹里创建文件。但是，如果你在开发一个很大型的项目，那么你可以把models分离出来放在一个或多个项目中。但是Controllers 和Views必须放在MVC项目中。对于每一个Controller，在Views下都会有名字与他想对应的文件夹。比如，如果有个名叫HomeController的Controller，那么在Views 文件夹里就必然又一个名叫Home 的文件夹。如果多个Controller需要使用同一个view，那么这个view就必须放在views文件夹的共享目录里。这个共享文件夹里也可以包含共享的用户控件，css文件，javascript文件等等。
kigg的相关知识和功能
在动手之前，先让我们探讨一下Digg/DotNetKicks类型程序的一些相关知识。这两个程序都是完全的社区驱动，人们在网上找到他们感兴趣的内容，然后在程序里提交。这些内容会立刻出现在upcoming story队列中。其他用户可以对这些文章投票，一旦投票达到某个数值，他就会出现在首页上。
程序的主要功能如下：
- 所有已经发布的Stories列表.
- 根据Stories的分类进行列表.
- Upcoming Stories列表.
- 根据Stories的标签进行列表.
- 根据Stories的发布用户进行列表.
- 搜索Stories.
- 查看Story的详细内容.
- 允许用户提交新的Story (需要登录)
- 允许用户对Story 进行Kigg (投票) (需要登录)
- 允许用户对Story 进行评论(需要登录)
- 允许用户登录.
- 允许用户注册
- 允许用户重设丢失的密码.
Controllers 和 Actions 的定义
Kigg的功能是和Story和用户有关的。所以我们可以把所有的功能归为以下两类:
-
StoryController: 处理所有Story的列表搜索提交投票等等。 -
UserController:处理身份验证，注册，忘记密码等等。
译注：这里的排版稍微变动了一下。把上面一句总述从列表里独立出来了。
建议使用实际的功能名称给Controller Actions命名。下面这些代码给出了StoryController里所以的行为方法：
注意所以的行为方法都定义为public并且使用了ControllerAction 属性。在下一个版本的ASP.NET MVC中这个属性就不再需要了，所有定义为公共的方法将自动成为一个行为方法。
定义筛选规则
一旦Controllers的参数签名确定就应该立刻开始声明把URLs映射到Controllers的行为方法的筛选规则。前面我提到过，这些映射规则在web.config文件中的application start事件中定义。定义筛选规则的时候你要注意，把最特殊的规则放在最上面。这个就跟try/catch块中定义错误处理规则一样，要遵循从特殊到一般的原则。如果你打开Global.asax 文件查看，你会发现我们明确的定义了两个方法来定义这些规则，并且在application start事件中调用方法。这么做是因为我们不想把不同版本iis中使用的规则弄乱。在iis7中有一个很cool的特性，所有的URLs都不需要扩展名，但是在老版本的iis中URLs都需要一个.mvc的扩展名。所以，为了同事支持这个两个版本的iis，我们就要把同一个URL定义两遍，为新的iis定义一套没扩展名的，为旧的iis定义一套有扩展名的。在这里，我们在web.confitg文件里设置当前程序是跑在什么版本的iis中，然后只把当前版本iis用的那套筛选规则读出来。这样做还有一个好处，那就是我们一会要讲的单元测试。下面这些代码展现了筛选规则是如何实现的：
如你所见，我们把类似User/Login, User/Signup, Story/Detail, Story/Category这类比较特殊的规则放在前面，而把Story/[action], [controller]/[action]这类一般的规则放在后面。当碰到变量时候，我们用[]来表示。MVC framework有两个固定的变量名：[controller]和[action]，其他的就用controller里行为方法的变量名来命名。最后一个规则我们把default.aspx映射到所有分类列表来处理路径/。
测试筛选规则
当上面那些筛选规则定义好以后，我们就应该立刻开始测试。这样就可以帮助我们确定现有的筛选规则能否很好的映射所有的controller行为和URL中传递的方法是否正确。下面这个表列出了我们想测试的所有映射规则：
Table 1: Tests
| Functionality | Url Format | Controller | Action |
|---|---|---|---|
| Login登录 | User/Login | UserController | Login |
| SendPassword发送密码 | User/SendPassword | UserController | SendPassword |
| Signup注册 | User/Signup | UserController | Signup |
| Logout注销 | User/Logout | UserController | Logout |
| List All Published Story列表所有发布的Story | Story/Category Story/Category/[page] |
StoryController | Category |
| List Published Stories for a specific Category 列表某一类别里所有发布的Storys |
Story/Category/[categoryName] Story/Category/[categoryName]/[page] |
StoryController | Category |
| List Upcoming Stories 列表Upcoming Stories |
Story/Upcoming Story/Upcoming/[page] |
StoryController | Upcoming |
| List Stories for a specific Tag 列表某一标签里所有Stories |
Story/Tag/[tagName] Story/Tag/[tagName]/[page] |
StoryController | Tag |
| List Stories Posted By an User 列表某一用户发布的Stories |
Story/PostedBy/[userName] Story/PostedBy/[userName]/[page] |
StoryController | PostedBy |
| Search Stories 查询Stories |
Story/Search?q=query Story/Search/[q]/[page] |
StoryController | Search |
| View Details of a Story查看一个Storie的详细信息 | Story/Detail/[storyID] | StoryController | Detail |
| Submit a Story提交一个Story | Story/Submit | StoryController | Submit |
| Vote a Story给一个Story投票 | Story/Kigg | StoryController | Kigg |
| Post a Comment发布评论 | Story/Comment | StoryController | Comment |
你可以在测试项目里找到我们测试所使用的Route.cs文件。我们同时创建了VSTSTest和NUnit两个版本的单元测试。我们用了Rhino Mocks来制作模仿对象。这些测试Phil Haack几个礼拜之前发布的Testing Routes In ASP.NET MVC一文里部分代码创建的。
译注：模仿对象是单元测试时常用的一种方法。
下面这些代码片段测试了筛选规则：
实现UserController
前面我们定义了UserController的签名，现在我们就来具体实现他。UserController使用了ASP.NET Membership provider来实现登录、注册和其他一些功能。这个controller和其他controller唯一的区别就是这个controller里所以方法都返回一个JSON数据而不是HTML输出。客户端通过ASP.NET AJAX Framework来调用这个controller里的方法。下面这些代码是Login方法的实现：
如你所见，我们在方法开头就创建了一个JsonResult对象。JsonResult是一个用来反馈controller行为是否成功的简单类，他只有两个属性isSuccessful和errorMessage, errorMessage。如果操作不成功，就把失败原因存在errorMessage里。在结尾处，我们把结果当作一个名为Json的共享视图里的view data返回。因为是一个共享视图，所以他可以被UserController和StoryController使用。我们把他放在了Views里名为Shared 的文件夹里。这个controller 里的其他方法工作原理都跟这个十分相似。我这里需要提到的一件重要的事情是，我们在构造函数里传递了一个抽象的membership provider来代替静态的Membership 类。这样做是因为在单元测试中我们可以传递一个模仿的Membership Provider，我们将在下一小节展示。在另一个构造函数中，我们传递web.config中定义的默认membership provider。
测试UserController
为了测试这个Controller，我们仍然使用Phil Haack前几周在Writing Unit Tests For Controller Actions一文中的方法。前面一小节说过，我们把一个模仿的Membership Provider传递过去来测试这个controller。我们预想在controller 调用这个membership provider然后能够得到正确的数据并发送给view。下面这些代码展示了正确的登录和当用户名为空时错误的登录：
综述
我最初想用一篇文章搞定所有问题，但是你也发现了，这篇文章实在是太长了。
译注：确实长的可以。
在这篇文章中，我们首先简单了解了一下ASP.NET MVC Framework，然后讲解了如何在controllers里定义功能，如何定义筛选规则并通过URLs测试他们，我们也看见了如何在Controller 中使用JSON 数据来代替完整的HTML视图。在本文的下一个部分里，我们讲着重讲解Controller，如何展示完整的HTML视图，使用master pages和user controls来创建视图，给视图发送强类型的view data和最后创建Model。就此停笔。