2.3 简说MVC

提到三层架构，很多人就会想到MVC（Model View Controller，模型-视图-控制器）模型。MVC的结构如图2-9所示。

图2-9描述了一个MVC框架处理用户请求的流程。

（1）用户发起请求，请求将被送给Controller。

（2）Controller去Model中取数据。

（3）Model返回数据给Controller。

（4）Controller将数据返回给View。

（5）View展示给用户。

如果这个流程让你觉得难以理解，不要担心，因为我们还没有开始写MVC的代码，所以我们无法理解用户请求为什么是到控制器（Controller）而不是到视图界面（View），最后返回的时候不通过控制器返回，而通过视图来返回……大家只需要对MVC有一个感性认识即可，知道每一部分是干什么用的就OK了。

2.3.1 纠正一下老师的说法

很多老师在讲到MVC的时候，都会和三层架构进行对比，并且会给出下面一幅图（如图2-10所示）。

老师画完这个图以后，告诉大家：MVC中的View和Controller相当于三层架构中的UI层。而MVC中的Model相当于三层架构中的BLL。

每当听到这样的解释时，MOL特别想问问老师：你把DAL层吃了？当然，这样的做法有点激进。但是，老师这样的讲法肯定是不对的。三层架构是一种思维，MVC是另一种思维，如果非要把二者放在一起对比的话，难免牵强。

接下来，我们来写一个MVC的程序，看看MVC到底是什么样子的。

2.3.2 MVC的第一个程序

前面提到过，MVC只是一种设计思想和程序框架，那么，也就是说MVC并不是.NET特有的，其他语言也有自己的MVC实现，我们在真实项目中使用的，其实也不是真正的MVC。但是第一个MVC程序一定要简单，所以我们使用微软提供的MVC来做。

微软在.NET 3.5以后的版本都支持MVC，这里使用的是.NET 4.5版本下面的MVC 4。好了，下面来新建一个Web项目，如图2-11所示。

如果读者以前用的是Visual Studio 2010，那么这个界面可能不太习惯。从Visual Studio 2012开始，WebForm、MVC、Web API等这样的Web项目都变成了一个“ASP.NET Web应用程序”，选择这个应用程序以后，单击“确定”按钮，进入选择项目类型步骤，如图2-12所示。

在这一步中选择MVC项目，然后单击“确定”按钮，进入项目解决方案的管理界面，如图2-13所示。

可以看到，在图2-13中，用标注框所标出来的地方就是我们前面所提到的Model、View、Controller。

打开HomeController.cs，修改Index方法为下面的代码：

public ActionResult Index()
{
       string msg = string.Format(@"这世界，我来了！");
       ViewBag.Message = msg;
       return View();
}

然后修改对应的Index.cshtml为下面的代码：

<div class="jumbotron">
       @ViewBag.Message
</div>

直接运行代码后会发现，我们写的文字已经显示在页面上了。页面效果如图2-14所示。

运行程序以后会发现，URL只是localhost：端口号，而没有实质的页面路径。我们把URL补全为localhost：端口号/home/index，还能看到相同的效果。通过这个简单的程序可以看到，用户（这里是浏览器）是向控制器（Controller）中的Action（这里是Index）发起请求，Action会进行数据处理（本例中是给ViewBag.Message赋值），然后返回给View（视图），View接收到返回数据以后，将数据显示到页面上，最后就可以通过浏览器看到效果了。

这段话里埋下了太多没有讲解的知识点。

（1）为什么localhost：端口号==localhost：端口号/home/index

打开App_Start下面的路由配置文件RouteConfig.cs，如图2-15所示。

可以看到这个文件中配置了一个叫Routes.MapRoute的对象。这个对象有一个默认属性defalts，表示当URL中没有控制器和Action的时候，指向哪个控制器下的Action。在本例中，它指向的是home/index。当然，这个默认设置是可以修改的。

（2）ViewBag是什么

在Index这个Action中使用了ViewBag对象，它是一个数据传递的载体，只需要为这个对象的属性赋值，前台就可以取到了，ViewBag的属性是不需要提前定义的，例如，要给ViewBag.Mol赋值为“帅”，那么前台就可以通过ViewBag.Mol来获取到“帅”。是不是很神奇？

除了ViewBag，还有一个叫ViewData的对象也可以完成类似的操作。它的用法是：ViewData["Mol"]="帅"；

关于ViewBag和ViewData的区别，这里不做详述，大家需要自行去学习。

（3）Model跑哪里去了

Model呢？前面用到了控制器和视图，单单把Model落下了。Model是一个实体集合，可以定义任何实体类。这个实体类可以是用户类，可以是订单类……可以把Model理解为这样一种东西：它是一种载体，通过这种载体，可以以面向对象的思维去处理数据。例如，定义一个User类，那么在控制器中就可以实例化一个User类，然后传给视图去展示。伪代码如下：

User user=new User();
user.name="Mol";
user.gender="male";
ViewBag.Person=user;

如果大家还不太了解MVC，那么就找一些资料学习一下。本书的重点不是MVC，所以这里只是略带一说。

2.3.3 为什么要用MVC之我见

其实MVC与传统WebForm的区别还是很多的，但是很多不同点还不足以引起大家使用MVC的欲望。这里只说几点大家可能会关注的地方。

• WebForm更容易上手，也就意味着程序员会忽略更多的细节。比如一个按钮是如何被解析成input标签的。这样的编程方式其实不利于对程序的理解。
• WebForm中设计了“生命周期”的模式，从页面出生到消亡，会经历很多个状态，比如常见的Page_Load就是其中的一个状态。这样多的生命周期，其实并不利于新手理解程序是如何处理请求的。
• WebForm页面中会保存大量的ViewState，这样就可以记住“之前”（事件触发前）的状态。这些ViewState会对优化工作造成不小的困扰，而且经常在程序员不注意的时候，页面就会狂飙到好几兆的大小。

如果你用过WebForm，也用过MVC，那么一定会觉得MVC是非常纯净的，因为它的流程透明，页面干净，不会生成意想不到的ViewState。

• WebForm中的页面都是继承自System.Web.Page类。而Page类是不可以实例化的，那么这种现象就会对单元测试造成很大的困难，有些程序员甚至直接跳过了单元测试。而在MVC中，所有的请求将会被汇集到Controller类中，而对控制器和其中的Action做单元测试是比较容易的。
• WebForm中的前台是aspx页面，也就是说这个前台页面并不是一个纯净的HTML页面。当程序员从美工手中接过静态页面的设计以后，需要把大量的input标签转换成按钮、单元框、文本框……这个枯燥的工作一定会把人逼疯的。
• 这一点其实算是个彩蛋，因为并不能算是一个非常直接的原因。把项目提交到Git上以后，Git平台中的“代码分析”功能会检查整个项目的代码完整性、可读性、规范性等。其中，规范性要求代码需要按照一定的命名规则来书写，而如果项目使用了WebForm，那么Page_Load这样的函数名就一定会被检查出来，并且还没有办法把它改成其他的函数名，这是多么的“坑爹”。

其他的区别还有很多，但以上所列几点已经有足够的理由让我们去使用MVC。

在本章中，我们将使用微软提供的MVC来做示例。在前面的内容中提到过，MVC只是一种编程思想，而不是某个公司或机构的专有技术，在后面的章节中，我们会引入Spring.NET中的MVC。 l2t0iWckC1y+eFWYbiAG2yZmZL10fitdZHKD1kPeOwHIcAF+HNz5qyHDxP7FtmRx