模型-视图-控制器（MVC）模式到底是什么？

由 Mux 赞助的 DEV 全球展示挑战赛：展示你的项目！

一切始于1979年，当时Trygve Reenskaug在施乐研究实验室为一款Smalltalk应用程序概述了模型-视图-控制器（MVC）模式。最初的实现旨在使用户能够控制并与庞大而复杂的数据集进行交互。这意义重大，对吧？然而，在MVC出现之前，许多应用程序都会面临一个反复出现的问题：业务逻辑、表示层和功能层混杂在一起。随着项目需求的变化，例如新增图形界面或数据源，应用程序的结构维护难度会越来越大。这反过来又会削弱系统的稳定性，最终可能导致完全重写。模型-视图-控制器模式（MVC）将业务逻辑、表示层和功能层拆分成独立的、自包含的部分。这意义非凡。MVC为应用程序开发树立了新的标准，并迅速被开发社区所接受。

在接下来的二十年里，许多新兴技术都采用了 MVC 架构模式。NextSTEP、Java Swing 和 Microsoft Foundation Classes (MFC) 只是其中几个值得注意的例子。随着万维网的快速发展和对 Web 应用日益增长的需求，MVC 模式被应用于 Jakarta Struts 和 WebObjects 等知名 Web 框架中。虽然这些框架基于简洁的 MVC 模式，但其晦涩的配置和缓慢的开发周期促使一些开发者构建一个能够以简洁的方式应用 MVC 模式的框架。于是，Ruby on Rails框架应运而生。接下来，让我们深入了解一下 MVC 模式本身。

模型

该模型的主要功能是访问和修改数据，同时保持应用程序的当前状态。

假设你开发了一个工资管理应用程序。数据库中存储了每位员工的每小时工资和每周工作时长。如果 Cliff 上周工作了 50 小时，那么需要计算 10 小时的加班工资，假设加班是指每周工作超过 40 小时的部分。为了让应用程序返回正确的 Cliff 工资，它需要进行一系列计算。这个模型就是用来存储和执行这些业务逻辑的。

在考虑数据模型时，必须理解任何不相关的数据组都应该成为独立的模型。每个数据组都是自包含的，这意味着理论上你可以添加和修改模型而不会影响其他数据集。

该模型提供数据，但不负责数据的显示。

看法

视图的主要功能是呈现应用程序中数据的显示方式。

我们再回到克里夫的工资单上来。为了生成格式正确的支票，我们需要显示所有相关信息——姓名、地址、金额和日期。这些信息如何在屏幕上显示，以及如何打印到支票上，都由视图来处理。

该视图允许应用程序显示同一数据的多种表示形式，例如 Cliff 的个人工资单、他所有工资单的列表，或者上周所有员工工资单列表中他的工资金额。所有这些实例都依赖于相同的模型来提供数据，但使用不同的视图来渲染数据。

该视图渲染数据，但不直接与模型通信。

控制器

如果把应用程序比作一个交响乐团，那么控制器就相当于指挥。控制器负责协调应用程序的流程，处理用户输入，然后向客户端返回相应的视图。

打印完克里夫的工资单后，你可能会反思他的工作表现，并决定给他加薪。你填写了修改员工工资的表格，然后点击保存按钮。控制器接收了你的输入，并通知模型执行相应的操作，在本例中，就是给克里夫加薪，这是他应得的。

用户交互的逻辑是在控制器中编写的。在我们的示例中，当您提交表单时，控制器会确定点击提交按钮后应该执行的事件序列。如果您要将记录保存到数据库，控制器可以调用相应模型中的 save 或 update 方法。数据保存后，控制器会确定接下来要向客户端呈现哪个视图。

控制器会同时与模型和视图通信，因为按照 MVC 模式，模型和视图不应该直接相互通信。

综合起来

模型、视图和控制器彼此独立。将来对这三个组件中任何一个的更改，对其他两个组件的影响都微乎其微甚至没有影响。

假设我们的薪资管理应用程序被另一家公司采用，他们希望重新设计界面以匹配其企业品牌形象。使用 MVC 架构，他们只需修改视图即可。该公司还计划迁往另一个国家，这意味着他们的薪资管理需求也会发生变化。同样，使用 MVC 架构，他们只需更新包含相应业务逻辑的模型即可。MVC 架构允许您在不影响其他功能的情况下，对某个区域进行调整。

许多 Web 应用程序使用主题，通过不同的样式表和模板文件，轻松切换各种设计和布局。例如，常见的博客应用程序或您喜爱的媒体播放器，它们都拥有众多皮肤。这两种应用程序都充分利用了 MVC 模式的优势，将用户界面与应用程序的逻辑和功能分离。同样，Ruby on Rails 也充分利用了 MVC 模式，它提供了一个预定义的结构，不仅使 MVC 易于遵循，而且还鼓励您在构建应用程序时考虑到未来可能发生的变化。

以我的经验来看，遵循 MVC 架构可以在需要进行意外修改时避免很多麻烦。