聊聊.net程序设计——浅谈MVC 架构模式（上）

最近总听一些人在讨论MVC、MVP、MVVM各种架构模式之间的关系及提升之处，自己也想写一些关于这3种模式相关的东西，同时来比较一下它们的区别。在日常开发中，我们有很多机会接触到MVC、MVP,MVVM也许是搞WPF及Silverlight的同事接触的多一些，但可以肯定的是无论采用哪种模式都是为了解决一些实际的问题。这3种模式是有一定的演化顺序的。大家都知道我们最先接触的是MVC然后是MVP接着最近几年的MVVM。它们分别解决的问题不同，使用的场景也不同，可以说各有各的用处各有各的好处。那么怎么来确认在什么时候采用哪种模式呢？也许只有在实际工作中使用过才可以做相关的选择。

其实、在实际工作中我对这3种模式只能说是使用过远达不到精通的地步。也许是一直在往前赶进度一直也没时间停下来好好总结一下，所以在这里想对这3种模式分别小总结一下。

言归正传吧，我们先来讨论一下MVC架构模式。我在工作这几年来最早接触的就是MVC（当时也没有后两种模式，哈哈），当时给我最直观的感受就是将M和V的实现代码分离，从而使一个程序可以有不同的展现形式；C就是用来衔接M和V的。其实MVC（(Model View Controler)）中，M——指数据模型、V——视图即用户界面、C——控制器。MVC是Xerox PARC在八十年代为编程语言Smalltalk－80发明的一种软件架构模式。

使用MVC是强制性的将输入、处理和输出分开，3个部分各司其职，首先来看View——视图都做些什么。

视图是用户与程序交互的接口，拿ASP.Net来说视图是由HTML及ASP.Net元素组成的界面，现在来说HTML还在扮演着主要的角色当然最近RIA很火，什么Flex、Silverlight等技术层出不穷，其实它们为的是改善用户体验，但说到最后也是视图。随之技术的更新，应用程序的界面变得越来越有挑战性，MVC的一个好处就是能使你的程序处理不同的视图，视图中并没有真正的逻辑。Microsoft的Asp.Net是基于事件驱动的也就是由控件的事件来实现其动作。例如Button 的Click等。真正的业务被封装在Model层。

Model——业务层，主要表示数据及其业务逻辑，模型拥有最多的处理任务。模型发布的数据是基于业务的，也就是说它与View没有直接的关联，换言之一个模型数据可以在多个视图中展现，这样可以减少代码的重复性。当然你还可以在Model与View层直接加个Service层这样可以将业务逻辑封装在服务内部，将服务暴露给外部使用者这样更松耦合，也更易于拓展维护。慢慢可以转向SOA，当然SOA又是一个很复杂的模式，以后有机会我们可以再讨论这里不再细说。包括以后有时间我们可以具体讨论一下WCF相关的知识。

然后就应该是Controler——控制器层了，控制器接受用户的输入并调用模型和视图去完成用户的需求。所以当单击Web页面中的按钮和提交时，控制器本身不输出任何东西和不做任何处理。它只是接收请求并决定调用哪个模型去处理请求，然后确定用哪个视图来显示模型处理返回的数据。

具体的处理过程，如下图：

 

（此图来源于互联网）

虽然图比较简单，但也已经将MVC的逻辑描绘出来了，我们首先来看用户通过View层接受用户输入，然后将输入传递给Controller，Controller决定应该由哪个Model来处理，然后Model来处理用户的请求最终返回结果数据，然后控制器在用视图格式化数据最终将结果展现给用户，这样就完成了一次交互。

以上就是对MVC整个逻辑表述，下面我们来说说用MVC有什么好处，为什么要用MVC，及使用MVC有什么不足之处？

使用MVC有什么好处呢？首先、最直观的是多个View可以共享一个Model，也就是说业务逻辑被单独封装用什么View则及其灵活，我们可以使用HTML，可以使用Flash，可以用Silverlight等等。这样就将表现层完全分离出去了实现了UI对业务的松耦合。这样大大提高了代码的可重用性。

因为模型是自包含的，并且与控制器和视图相分离，所以很容易改变你的应用程序的数据层和业务规则。举个例子，假如说我们原来后台数据库使用的是Oracle的，由于客户需求现在要换成SqlServer或者MySql，原来我们可能要做翻天覆地的更改，重构。但使用MVC我们只需要改变Model即可。以为Model层是自包括的所有不会对其他两层造成影响，这样我们就使改动量降到了最小，拓展性升到了很高。

上面说了很多MVC 的优点，但物无完物人无完人，没有什么东西是没有缺点的，MVC虽然强大，但MVC没有真正明确的定义，使用MVC要精心细致的设计，其实现比较复杂前期要花大量的时间进行设计。要花时间考虑如何将MVC与程序结合，每个层都需要细致的测试。带来灵活性的同时就会带来设计的复杂度，对各种约定的抽象及其实现都需要花时间来考虑。MVC原来一般不推荐在小项目中使用，但经过一段时间的历练后该模式的使用也相对成熟平台也对其进行了封装，所以在使用方面也大大简化了许多，例如微软的Asp.Net MVC就是典型的例子。

总之，MVC也是一把双刃剑，我感觉什么东西一定要各得其所，在需要用的时候用，不需要用的时候不要强搬硬套最后自己给自己找麻烦。具体的度还要经过时间的历练自己慢慢总结慢慢去感受。

这篇只是对MVC架构模式理论上的一些讲解，下篇准备用一个例子来更深入了解一下（最近一直在加班，先许个愿）。

有不足之处，还请各位指出，谢谢！