三层架构和MVC模式
八月的第二周，来整理工作一个多月对于架构、模式的认识。
反思了一下，博客内容应该是自己在学习过程中的总结与思考，而不应该是科普与教学，应当写得更倾诉一些。
今天要整理的内容有两方面，一种是三层架构，另一种是MVC模型。
架构，是指设计一个程序的结构，是一个相当宏观的概念。
我觉得要理解架构这个概念，最主要的是去把握宏观这个特征。换句话说，当考虑架构的时候，是不去思考软件的应用场景、实现细节这些的，而是站在一个统领全局的角度，去思考一个庞大的程序应该怎么部署的。
一个庞大的程序，应当采用什么样的结构，应当划分成哪几个模块，怎么设计才能实现高效开发，才能让一群码农共同实现进度，这是架构要去解决的问题。所以你看，这真的是一个很宏观的问题，是一个统筹部署的设计问题。
有许多被广泛使用的架构模式，其中最简单、最基础的是三层架构，我们来聊聊这种架构。
三层架构
三层架构是指，把一个项目拆成三层：第一层跟用户打交道，第二层处理业务逻辑，第三层处理数据库。
这三层的名字分别叫做表示层（PL）、业务逻辑层（BLL）、数据访问层（DAL）。
这三层的名字起得相当虎逼，煞有其事的，其实指的是很简单的东西。
- 表示层：给用户看的，给用户操作的。
- 业务逻辑层：后台处理，干活的。
- 数据访问层：管数据的。
一个项目拆成了 数据 —> 处理 —> 展示 三个部分，竖着看是不是三层。
你稍微一想，就会觉得这么分层是挺有逻辑、挺有道理的。不用说编程，做什么事情不都是这样子吗：首先拿到原材料，然后加工处理，最后展示出去。尽管有很多细节不一样，但是大致的流程就是这样子的。
通过三层架构，把一个项目的全部内容拆成三个层面的事情。最上面一层只跟用户打交道，用户看到什么，用户操作什么，用户输入了什么，全都在这一层；中间一层只跟业务逻辑打交道，拿到数据怎么处理，收到用户信息怎么加工，全在这一层；最底下一层只跟数据打交道，数据存放在哪里，怎么取出来，怎么把新数据存进去，全在这一层。
这种架构能够实现初步的“分而治之”，把大事拆成小块，每一部分做自己的事情，这是为了编程中的“解耦”。解耦就是解除耦合，关联得不要那么密切，这样好开发。
关于三层架构先说到这里。
设计模式是针对于某一类场景而言的，是一个不太宏观的概念。
当面对着某一类情况，尽管细节上各有不同，但是这类情况有共性之处，有可以解决这类情况的一种方案，这就是设计模式。
你可以感受到，架构和设计模式不是同一高度的，架构非常宏观，设计模式没那么宏观，这是两个纬度的概念。再换个说法，架构面对的是所有情况，设计模式面对的是某一类情况。
我很努力地去表述，架构与设计模式不是同一个纬度的东西，尽管它们都是用来解决泛化场景的，但是层级是的的确确有差异的，设计模式是比架构低一个level的东西。这样去表述的目的，是为了解释清楚一个经常被问到的代码相关问题：三层架构与MVC模式的区别是什么？
现在我先这么回答：
三层架构是一种架构，MVC模式是一种设计模式，它们解决问题的高度不同：
三层架构是为所有情景设计的，MVC模式是为其中一类情景设计的。
接着来聊一聊MVC模式。
MVC模式
MVC是Model-View-Controller的首字母合称，就是说把一个软件项目拆成三个基本部分——模型（Model）、视图（VIew）、控制器（Controller）。
你首先要认识到，MVC模式不是为所有场景设计的，它只是web应用的一种设计模式。为了更好地开发网页，前人设计了一种名叫“MVC模式”的设计模式，它就是为了web应用开发而存在的。
然后我们来仔细说说MVC模式是什么。
MVC模式有三个部分，但是为了说明方便，还要在这三个部分之外加上“人”的角色（也就是用户），来理解人是怎么跟这三个部分打交道的。
我画了一张图，你能够看到MVC其实就是三个模块，与人直接打交道的是View和Controller模块：人看View模块（例如看静态网页、看网站视频），人操作Controller模块（例如点击鼠标选择）；而Model模块是藏在后面的，是View模块和Controller模块的桥梁。
也就是说：
- Model（模型）：后台处理逻辑
- View（视图）：可视化部分
- Controller（控制器）：
听到了一声灾厄。
不想写下去了，这一篇就写到这里吧。