MVC是一种很古老的软件架构模式。这种模式对于计算机刚出来时是一种比较完备或者比较适用的描述。
但是随着时间的流逝，软件变得越来越复杂，MVC这种结构就会看上去显得不准确。但是我们只要能基于巨人的肩膀跳出来看问题，我们就能更好的理解MVC结构的价值。
首先我们来看看什么是MVC。
简单来说
M：就是模型，英文原文是Model。
他的意思就是对基本业务单元的抽象。但是这种业务更多是指对可存储的数据模型的抽象。
C：就是控制，英文原文是Controller。
他的意思就是对基本业务处理的抽象。但是更多的偏向于非存储的业务模型的抽象
V：就是视图，英文原文是View。
他的意思就是对于人机界面交互处理的抽象。但是更多的是偏向于如何展示的人类可见的界面。
M，V，C三者是对计算机系统或者软件最简单的抽象，而实际的计算机系统或者软件往往是对这三块的丰富，所以本质是要比MVC复杂的。
所以我们在这里再深入的讨论MVC模型下面的子模型。
首先是M这个部分。
M作为数据部分，
我们可以想象的到的实物产品有：
1.磁盘或者存储盘（包括光盘，U盘，硬盘，存储阵列等）
2.内存
3.网络（包括有线，无线的数据传输介质）
我们可以想象到的软件产品有：
1.数据库(Mongodb, Mysql, Oracle等）
2.文件
3.管道
4.共享数据
5.缓存等(CPU缓存，Session缓存，加速缓存等)
所以我们可以看出来M这个概念本身就是非常广泛的。我们列出来的都是概念上的M，而在实现M的过程中，必然会同样涉及到M里的MVC。
比如我们的Msql数据库，
- 首先Mysql必然有文件作为存储媒体保存数据库的信息，我们可以将文件当成是Mysql的M
- 同时Mysql具备自己的SQL语言，可以将对SQL语言的解析当成是C
- 而Mysql是有命令行的操作界面的，这个界面可以称为V。当然Mysql也推出了基于图形的界面工具Mysql workbench，还有一些其它的图形工具比如navicat之类的，都可以称为Mysql产品的View端
所以我们可以看到在一个M产品里，仍有一个完整的MVC链
然后我们再看看V这个部分
软件领域的V我们大概可以看到以下三类V
- 手机端的V
- 桌面端的V
- Web的V
那么这么View里一般会包含有 - 视窗( window)
- 菜单
- 按钮
- 进度条
- 文本框
…
等等
我们可以看到大部分的菜单，按钮，都是包括 - 文字（M）
- 控件能力（C）
- 外观设计（V）
这三个部分的。
那么从MVC的角度来看，这三者组成了一个完整的MVC。
所以V也是递归的MVC结构
最后我们看看C的部分
C的部分相对来讲更加的广泛一点。因为C的部分除了通用的部分外，还有很多专用的内容。
所有的软件从本质来讲都是C。
也就是所有的软件都是为了达成某一种控制目标而存在的。
C就是控制器，我们可以想象到的最常见的物理上的控制器就是CPU，键盘，鼠标。
而软件上最常见的就是协议，指令，信号，业务逻辑等。
他的作用是让我们的所有信号按照预定的方式执行。
那么C部分有没有MVC的递归性呢？C部分的MVC递归性看上去要显的弱很多。
- 首先我们可以看到的是C部分所处理的所有内容都是数据，我们可以将他看成是M。
- C部分天然拥有很多的控制代码与业务处理，将他们理解成C也是没有任何问题的
3.那么View在MVC的C里有没有呢？
如果单纯从可视化来讲，C是可以没有V的。
但是C的View是可以表现在接口上的，也就是通常我们理解的API或者SOAP等。
这是一个机器的View。人类理解它们会有文档，会有对这个接口的描述。
但是C里也是可以有可视的V的。目前来讲大部分的运行监控都是针对C的处理能力的监控。
比如处理了多少的用户，调用了多少次API，使用了多少的内存，完成了多少次请求等等。
因些我们可以发现，除了我们在C部分遇到了一点点困难外，我们很轻松的将MVC递归的拆分成功了。
并且当我们将MVC的递归性应用到更多的领域时，我们就很容易理解真正的MVC的意义是什么。
比如在Web领域。
后端可以更加明确成一个MVC的变种： RRRMVC
RRR => (Request Route Response)
目前Web Component就是一个MVC组件，将MVC全部包装在一起然后供上层MVC调用。
还有一种是MVVM变种：
将V与M通过C绑定，让其它的C独立出来不再做绑定的工作。
结论
MVC是一种对基本的计算模型的抽象，他会随着时间的变化而变化，但是当你回到最小数据集去描述一个程序或者软件时，MVC还是最适用的一个模型，我们去理解MVC时，不应该直接去否定MVC的价值，而是找到MVC的本质，理解新的变种与MVC本身之间的关系，这样我们才能更要的利用MVC模型，达成我们自己的需要。
