MVC

http://blog.csdn.net/pi9nc/article/details/18822325

先前整理过一篇文章，讲的是如何使用Php搭建Mvc框架，前几天看了一些文章，对MVC又有了新的认识，具体整理如下：

   一、Classic MVC

   MVC模式(Model-View-Controller)是软件工程中的一种软件架构模式，把软件系统分为三个基本部分：模型(Model)、视图(View)和控制器(Controller)。最早由Trygve Reenskaug在1978年提出，并应用在Smalltalk系统中。

模型(Model)，用于存储程序中使用到的数据;
视图(View)，用不同的表现形式来呈现数据；
控制器(Controller)，更新模型。

在维基百科对 MVC 体系结构的定义中，它由如下三部分组成：
模型（Model） -“数据模型”（Model）用于封装与应用程序的业务逻辑相关的数据以及对数据的处理方法。 “模型”有对数据直接访问的权力。 “模型”不依赖“视图”和“控制器”，也就是说，模型不关心它会被如何显示或是如何被操作。
视图（View） - 视图层能够实现数据有目的的显示，通常是一个用户界面元素。在视图中一般没有程序上的逻辑。在 Web 应用程序中的 MVC，通常把显示动态数据的 html 页面称为视图。
控制器（Controller） - 处理和响应事件，通常是用户操作，并监控模型上的变化，然后去修改视图。

 Classic Mvc模式：

• Model：封装领域数据及逻辑。用于管理应用程序域的行为和数据，并响应为获取其状态信息(通常来自视图)而发出的请求，还会响应更改状态的指令(通常来自控制器)。

• View：查询领域数据并展现给用户。用于管理信息的显示。

• Conctroller：截获用户请求并改变领域数据。用于解释用户的鼠标和键盘输入，以通知模型和/或视图进行相应的更改。

从依赖关系看，Model不依赖View和Controller，而View和Controller依赖Model。

   Classic MVC关注两个分离：

• 从Model中分离View

• 从View中分离Controller

 从Model中分离View，主要基于以下几点考虑：

• 不同的关注点：Model关注内在的不可视的逻辑，而View关注外在的可视的逻辑。

• 多种表现形式：同一个Model往往需要多种View表现形式。

• 提高可测试性：相对Model而言，View是不容易测试的。

Desktop软件的时代，View和Controller往往是一一对应的关系，所以常常把他们合并成为UI，事实上，当时多数UI框架都没有实现从View中分离Controller。后来随着Web的兴起，这种分离(模板技术)才开始流行起来。

   本质上Classic MVC的结构如下图所示，之所以说本质上，是因为View和Controller其实是彼此关联的，但这种关联和稍后提到的MVP完全不同，更像是一种框架的副产品，为了避免引起混淆，这里省略了它们，具体参阅：How to use Model-View-Controller (MVC)

• Controller截获用户通过鼠标或键盘发出的请求，然后改变Model的状态，Model通过Observer Synchronization(观察者模式)通知View自己的状态发生了变化。View查询Model展现数据。

     Classic MVC并不完美，不适用于复杂的逻辑。举个例子：用户通过鼠标拖动滚动条来调整音量大小，如果音量大于某个数值，背景色变红以示提醒。当使用Classic MVC的时候，如何处理背景色变红的逻辑呢？

     有两个选择：

• Model触发一个特殊事件，View收到后完成相关逻辑的处理。但我们前面说过，从依赖关系上看，Model应该完全无视View的存在。

• 在View中判断音量临界值，达到后完成相关逻辑的处理。但我们前面说过，View是不容易测试的，应该尽可能减少逻辑处理。

     Classic MVC并不完美，不适用于复杂的逻辑。举个例子：用户通过鼠标拖动滚动条来调整音量大小，如果音量大于某个数值，背景色变红以示提醒。当使用Classic MVC的时候，如何处理背景色变红的逻辑呢？有两个选择：

• Model触发一个特殊事件，View收到后完成相关逻辑的处理。但我们前面说过，从依赖关系上看，Model应该完全无视View的存在。

• 在View中判断音量临界值，达到后完成相关逻辑的处理。但我们前面说过，View是不容易测试的，应该尽可能减少逻辑处理。

     上述只是提出了Classic MVC的一些缺陷，那到底如何解决呢？请继续关注下文~

     二、Application Model MVC

     大概上世纪八十年代，ParcPlace从Xerox Parc划分出来，负责Smalltalk的研发工作，为了适应更复杂的逻辑，开发了Classic MVC的改进版，也就是Application Model MVC，在原有架构基础上引入了Application Model，如下图所示：

......

 

http://www.jianshu.com/p/734b7517a6de

图解：一个典型的Web MVC流程
1、Controller截获用户发出的请求
2、Controller调用Model完成状态的读写操作
3、Controller把数据传递给View
4、View渲染最终结果并呈献给用户
在Web MVC中，Controller变成了中继者，主要工作是协调Model和View

1、 什么是MVC (模型 视图 控制器)?
MVC是一个架构模式，它分离了表现与交互。它被分为三个核心部件：模型、视图、控制器。下面是每一个部件的分工：
视图是用户看到并与之交互的界面。
模型表示业务数据，并提供数据给视图。
控制器接受用户的输入并调用模型和视图去完成用户的需求。

2、你能解释下MVC的完整流程吗？
下面是MVC（模型、视图、控制器）架构的控制流程：
(1)所有的终端用户请求被发送到控制器。
(2)控制器依赖请求去选择加载哪个模型，并把模型附加到对应的视图。
(3)附加了模型数据的最终视图做为响应发送给终端用户。

3、MVC同时适用于Windows应用和Web应用吗?
相比Windows应用，MVC架构更适用于Web应用。对于Windows应用，MVP(Model View Presenter )架构更好一点。如果你使用WPF和Silverlight，MVVM更适合。

4、使用MVC有哪些好处?
分离了关注点。后台代码被移到单独的类文件，我们可以最大限度的重复利用代码。
自动化UI测试成为可能，因为后台代码移到了.NET类。这让我们更容易做单元测试和自动化测试。

5、MVC的最新版本是哪个?(ASP.NET MVC)
MVC 5.1
发布日期：（2013年）
MVC 6.0
发布日期：（2016年?月）（正式版发布日期待定）

6、MVC的缺点？
MVC的缺点是由于它没有明确的定义，所以完全理解MVC并不是很容易。使用MVC需要精心的计划，由于它的内部原理比较复杂，所以需要花费一些时间去思考。
你将不得不花费相当可观的时间去考虑如何将MVC运用到你的应用程序，同时由于模型和视图要严格的分离，这样也给调试应用程序带来了一定的困难。每个构件在使用之前都需要经过彻底的测试。一旦你的构件经过了测试，你就可以毫无顾忌的重用它们了。　　根据开发者经验，由于开发者将一个应用程序分成了三个部件，所以使用MVC同时也意味着你将要管理比以前更多的文件，这一点是显而易见的。这样好像我们的工作量增加了，但是请记住这比起它所能带给我们的好处是不值一提。　　MVC并不适合小型甚至中等规模的应用程序，花费大量时间将MVC应用到规模并不是很大的应用程序通常会得不偿失。