一句话MVC架构：拆开面子和里子，再使用有结构的数据管道连在一起。
近期学习了MVC的软件架构。期间不禁得思考这样的架构是否可以作为支撑日常生活计划甚至是思考的模型。
从旁观者的角度审视MVC架构，我们可以给出如下的解释：
- 界面View注重交互，强调数据的输入和输出展示。
- 业务逻辑Control注重的数据的处理，包括计算、存储。
- 数据模型Model注重的是数据的格式，封装界面和业务逻辑间传递的数据。
- MVC的目的是分离界面View和业务逻辑Control，并使用数据模型Model打包整理数据。
- 维护更加便捷，添加功能更容易。
明白了上面的内容，接下来我们站在程序的立场上，思考一下MVC这个架构。
我们有两个主人公小V小C，还有叫做M的箱子。小V喜欢社交，经常会展示各种各样有意思的东西给人看，也会收到很多的礼物。他会把一大堆的礼物按照箱子M上标注的顺序装好，送给小C。小C是技术宅，喜欢把箱子M里的东西拆拆合合，重组融合。然后再把数据收到一个箱子M，可以是不同的箱子M，然后在送回小V。小C和小V是好朋友，他们会帮助对方做事情。
我们注意到，在这个小情景剧里，数据模型箱子M起到的作用是规范数据的传递，帮助界面小V和业务逻辑小C互相之间送礼物也就是数据。我们还注意到，小V和小C一个专注对外一个专注对内，除了使用箱子传递数据就只有互相调用的关系，是一种很强的绑定。
在生活中是否有这样的场景呢？有的，而且很多。像是我们有一个小组，其中有组长和组员。组长负责指挥和对外的沟通，组员负责执行具体的任务。组长和组员之间沟通的方式是是规范好的申请表、报告书还有任务通知书。其中组长是界面V，组员是业务逻辑C，满天飞的文档是数据模型M，一套标准的MVC架构。
说了这么多，到底如何在日常生活中使用MVC的思想呢？
MVC本质依然是一个框架，是一个解决问题题的模板，他告诉我们在设计解决一个问题的方法的时候要拆分能看到表面的逻辑和隐藏好的背后的逻辑，并且两部分逻辑要有条理的连接在一起。
当我们遇到了一个难题，我们首先识别这个难题的题面（View）给我们提供了哪些信息。其次我们思考这些信息是怎样进入这个题的背景，目的是寻找封装信息（Model）的最好方法。最后我们根据封装好的信息设计解决难题的方法（Control）。
相较于遇到问题直接就开始写解答的意识流，这种 MVC 迁移过来的思想能够降低问题的复杂性，帮助我们设计解题流程。
