【设计思想】MVC模式

MVC 模式

MVC 模式（三层架构模式）

MVC模式(Model-View-Controller, MVC)： 是软件工程中的一种软件架构模式，把软件系统分为三个基本部分：模型（Model）、视图（View）和控制器（Controller）。
理解：MVC: M is between V and C

MVC模式的目的是实现一种动态的程序设计，使后续对程序的修改和扩展简化，并且使程序某一部分的重复利用成为可能。除此之外，此模式通过对复杂度的简化，使程序结构更加直观。软件系统通过对自身基本部份分离的同时也赋予了各个基本部分应有的功能。专业人员可以通过自身的专长分组：

• 控制器(Controller)：负责转发请求，对请求进行处理。
• 视图(View)：界面设计人员进行图形界面设计。
• 模型(Model)：程序员编写程序应有的功能（实现算法等等）、数据库专家进行数据管理和数据库设计(可以实现具体的功能)。

为什么叫MVC

MVC 的命名顺序 并非基于运行时的「调用 / 执行顺序」 ，而是源于「架构设计的逻辑优先级 + 关注点分离的核心思想」，简单说：命名顺序是「设计层的优先级」，而非「运行时的执行流」。

一、先搞懂：MVC 每层的核心职责（命名的底层逻辑）

MVC 是软件工程中经典的 分层架构模式 ，核心是把「数据处理」「界面展示」「交互控制」拆分开，每层只做自己的事。先明确每层的定位，才能理解命名顺序：

组件	全称	核心职责	定位（设计优先级）
M	Model（模型）	封装数据、业务逻辑、数据校验 / 存储（比如数据库操作、计算规则）	应用的核心 / 灵魂 （最稳定、最核心）
V	View（视图）	展示数据（Model）、接收用户直观操作（比如点击、输入）	数据的表现形式 （依赖 Model，易变）
C	Controller（控制器）	协调 Model 和 View：接收 View 的交互指令 → 调用 Model 处理数据 → 通知 View 更新展示	连接 M/V 的桥梁 / 协调者 （依赖前两者）

二、为什么是 MVC 这个顺序？（核心原因）

MVC 的命名顺序，是按「 设计阶段的思考顺序 + 组件的核心程度 」排序，而非运行时的调用顺序：

1. 设计逻辑优先级：「核心先行」

架构设计时，我们首先要确定「应用的核心是什么」—— 是数据和业务规则（Model），而非界面或交互。

• 比如做一个电商系统：先定义「商品 Model」（价格、库存、分类）、「订单 Model」（下单规则、支付逻辑），这是系统能跑的基础；
• 再设计「商品 View」「订单 View」（怎么展示这些数据，列表 / 详情页）；
• 最后设计「控制器」（处理用户点击 “加购”→ 调用 Model 扣库存 → 通知 View 刷新购物车）。

命名顺序 M→V→C 完全贴合「先定核心（M），再做展示（V），最后加控制（C）」的设计思考流程。

2. 历史由来：贴合最初的设计理念

MVC 最早由 Trygve Reenskaug 在 1970 年代为 Smalltalk-80（面向对象编程语言）设计，当时的核心思路是：

「Model 是应用的核心，View 是 Model 的 “可视化投影”，Controller 是调节 Model 和 View 交互的 “中间人”」。

命名顺序直接反映了「Model 为核心，View 依附 Model，Controller 辅助协调」的层级关系，而非执行顺序。

3. 关注点分离的核心：「独立层优先」

MVC 的核心价值是「解耦」：Model 可以脱离 View/Controller 独立存在（比如换个前端框架，Model 逻辑不用改），但 View/Controller 无法脱离 Model。

命名时把最独立、最核心的 Model 放在第一位，符合「核心组件优先」的命名习惯 —— 就像我们说「汽车（核心）- 外壳（展示）- 操控系统（协调）」，而非按「踩油门（操控）→ 发动机（核心）→ 仪表盘（展示）」的执行顺序命名。

三、对比：MVC 的「命名顺序」vs「实际调用顺序」

为了更直观，用「用户查询商品详情」的场景举例：

1. 实际调用 / 执行顺序（运行时）

用户操作 → Controller → Model → Controller → View

1. 用户点击“商品详情”（View 接收操作）
2. View 把指令传给 Controller（比如传递商品ID）
3. Controller 调用 Model 的「查询商品」方法
4. Model 从数据库获取数据，返回给 Controller
5. Controller 把数据传给 View
6. View 渲染并展示商品详情

可见，运行时的核心执行流是 V→C→M→C→V，和 MVC 命名顺序完全不同。

2. 通俗比喻

把 MVC 比作「餐厅」：

• Model：后厨（核心，负责做食物 / 数据）
• View：餐桌 / 菜单（展示食物 / 数据）
• Controller：服务员（协调后厨和顾客）

命名顺序「后厨→餐桌→服务员（M→V→C）」是按「餐厅的核心功能→展示形式→协调者」排序；

而实际调用顺序是「顾客（用户）→ 服务员（C）→ 后厨（M）→ 服务员（C）→ 餐桌（V）」，和命名顺序无关。

总结

1. MVC 命名顺序（M→V→C）是 设计逻辑优先级 ：核心数据层（Model）→ 展示层（View）→ 协调控制层（Controller），而非运行时的调用顺序；
2. 调用顺序是「用户 / View → Controller → Model → Controller → View」，和命名顺序无关；
3. 核心本质：MVC 命名的核心是体现「关注点分离」的架构思想 ——Model 作为核心独立存在，View 和 Controller 围绕 Model 协作。

MVC 工作原理

MVC： 是一个设计模式，它强制性的使应用程序的输入、处理和输出分开。

使用 MVC 应用程序被分成三个核心部件：模型、视图、控制器。它们各自处理自己的任务。

视图

视图：是用户看到并与之交互的界面。

对老式的 Web 应用程序来说，视图就是由 HTML元素组成的界面，在新式的 Web 应用程序中，HTML 依旧在视图中扮演着重要的角色，但一些新的技术已层出不穷，它们包括 Macromedia Flash 和像 XHTML，XML/XSL，WML 等一些标识语言和 Web services. 如何处理应用程序的界面变得越来越有挑战性。MVC 一个大的好处是它能为你的应用程序处理很多不同的视图。在视图中其实没有真正的处理发生，不管这些数据是联机存储的还是一个雇员列表，作为视图来讲，它只是作为一种输出数据并允许用户操纵的方式。

模型

模型：表示企业数据和业务规则。

在 MVC 的三个部件中，模型拥有最多的处理任务。例如，它可能用像 EJBs 和 ColdFusion Components 这样的构件对象来处理数据库。被模型返回的数据是中立的，就是说模型与数据格式无关，这样一个模型能为多个视图提供数据。由于应用于模型的代码只需写一次就可以被多个视图重用，所以减少了代码的重复性。

控制器

控制器：接受用户的输入并调用模型和视图去完成用户的需求。

当单击 Web 页面中的超链接和发送 HTML 表单时，控制器本身不输出任何东西和做任何处理。它只是接收请求并决定调用哪个模型构件去处理请求，然后确定用哪个视图来显示模型处理返回的数据。

总结：现在我们总结 MVC 的处理过程，首先控制器接收用户的请求，并决定应该调用哪个模型来进行处理，然后模型用业务逻辑来处理用户的请求并返回数据，最后控制器用相应的视图格式化模型返回的数据，并通过表示层呈现给用户。

常见问题

框架和设计模式的区别：
有很多程序员往往把框架模式和设计模式混淆，认为 MVC 是一种设计模式。实际上它们完全是不同的概念。
框架、设计模式这两个概念总容易被混淆，其实它们之间还是有区别的。

• 框架通常是代码重用；
• 而设计模式是设计重用；
• 架构则介于两者之间，部分代码重用，部分设计重用，有时分析也可重用。

在软件生产中有三种级别的重用：

• 内部重用：即 在同一应用中能公共使用的抽象块；
• 代码重用：即 将通用模块组合成库或工具集，以便在多个应用和领域都能使用；
• 应用框架的重用：即 为专用领域提供通用的或现成的基础结构，以获得最高级别的重用性。

框架与设计模式虽然相似，但却有着根本的不同。

• 设计模式是对在某种环境中反复出现的问题以及解决该问题的方案的描述，它比框架更抽象；
• 框架可以用代码表示，也能直接执行或复用，而对模式而言只有实例才能用代码表示；
• 设计模式是比框架更小的元素，一个框架中往往含有一个或多个设计模式，框架总是针对某一特定应用领域，但同一模式却可适用于各种应用。

总结：可以说，框架是软件，而设计模式是软件的知识。

• 框架模式有哪些？
  MVC、MTV、MVP、CBD、ORM 等等。

• 框架有哪些？
  C++语言的 QT、MFC、gtk；Java 语言的 SSH 、SSI，php 语言的 smarty(MVC 模式)；python 语言的 django(MTV 模式)等等。

• 设计模式有哪些？
  工厂模式、适配器模式、策略模式等等。

简而言之：
框架是大智慧，用来对软件设计进行分工；
设计模式是小技巧，对具体问题提出解决方案，以提高代码复用率，降低耦合度。