从Web开发者的视角来解读MVC架构

Posted 2021-05-01 51CTO官微

原文标题：An Introduction to MVC Architecture: A Web Developer's Point of View，

MVC代表了一种软件框架的设计模式。该框架的主要功能是：通过允许多名开发人员共同在一个项目上开展工作，以分离应用程序的功能、逻辑和接口，进而促进有组织的编程实现方法。下面，让我们从Web开发人员的角度来解读MVC的不同组件。

首先，让我们来看看有哪些使用到了MVC的流行Web框架：

1. Ruby on Rails (Ruby)

2. Express (JS)

3. Backbone (JS)

4. Angular (JS)

5. Laravel (php)

6. Zend (PHP)

7. Codeigniter (PHP)

8. Django (Python)

9. Flask (Python)

接着，我们重点来讨论Ruby on Rails和Codeigniter(PHP)。这两个框架在它们的文件结构中有着不同的文件夹，也就是所谓的模型、视图和控制器。虽然类似并借用了Django for Python的某些概念，但是这两个框架实际上并没有严格的文件夹结构。

此类框架的另一个特点是：同一个框架可能会将其应用程序放置在控制器中，然后将另一部分放置在模型中。因此不少Web开发人员认为MVC架构略显混乱，甚至毫无固定章法可循。不过我个人认为：用户能够采用多种方式来创建MVC架构，正是其亮点与灵活性所在。

下面，我们正式从Web开发者的角度为大家解读MVC的三个组件：模型、视图和控制器。

模型

由于模型部件负责获取和操作数据，因此它一般属于应用程序的“大脑”。通常情况下，它与mysql之类的关系型数据库，以及MongoDB之类的NoSQL数据库进行交互。不过这并不重要，在支持多种数据库的不同框架中，模型的代码能够一直保持相同。

在实际应用中，我们只需要修改数据库的驱动程序便可，而不必知晓与之协作的数据库类型。例如：您完全可以让自己的模型与JSON文件进行交互，并从中提取数据。而这个简单的JSON文件甚至都不算是一个数据库。

模型不但能够负责诸如SELECT、INSERT、UPDATE和DELETE之类的查询操作，还能够与控制器进行通信。在大多数情况下，控制器可以通过模型来请求数据，并且由控制器来更新视图。不过，通过某些框架，模型也可以直接去更新视图。当然，这显然增加了MVC的复杂性。可见，不同的框架有着截然不同的实现方式。

视图

就视图而言，顾名思义它与应用程序的实际视图有关，也就是我们常说的用户界面。它负责面向用户的显示，以及让用户如何与应用程序进行交互。

因此，视图通常包括：html、CSS、以及来自控制器的各种动态值。在应用运行时，控制器会与视图、以及模型保持通信。同样，根据您所选用的框架不同，具体的模板引擎也可能会有所差异。

此处的“模板引擎”是指：某个允许动态数据的工具。如果我们使用的是直接的HTML，那么就不可能有各种输出变量，也无法选用if语句之类的逻辑。但是如果使用了模板引擎，那么我们就可以在视图中、或者是在模板中正确地处理此类动态变量了。

因此，模板引擎的典型示例包括：Handlebars.js(https://handlebarsjs.com/)与Dust.js(https://www.dustjs.com/)。对于Ruby on Rails而言，我们可以使用嵌入式的ERB(https://ruby-doc.org/stdlib/libdoc/erb/rdoc/ERB.html)。而对于Ruby语言，我们也可以使用Haml(http://haml.info/)和针对Python的Flask(http://flask.pocoo.org/)。当然，我们还有其他的选项，比如说javascript。

控制器

最后是控制器，它与用户的输入有关。例如：用户在访问页面时点击某个链接，触发了一个GET请求;或者是以提交表单的形式，发送一个POST请求;当然我们也可以发出删除、或提出更新等类型的请求。由于这些动作无法直接从浏览器中生成，因此您只能自行产生一个GET或POST，或者是通过内置在某个框架中的HTTP客户端，来达到该目的。

在此，控制器充当的是模型与视图之间的中间人角色。控制器需要通过模型从数据库中获取某些数据，而控制器在获取到相关数据之后，通过加载视图的方式，将该数据传递给它。接着，模板引擎接管后续的“任务”，实现输出变量之类的逻辑事务。

当然，控制器也可以在不传递数据的情况下加载某个视图。而此处需要有一个带有HTML和CSS的纯Web页面，就不是真实的模板逻辑。

下面是一个非常简单的例子(或称流程图)。

如上图所示，用户可以通过浏览器看到应用程序的视图。

首先，应用程序可以将他们的输入作为某种请求提交给所谓的“路由器”。而且这些请求正是用户通过点击某个链接，所产生并触发的某条路径需求。

接着，“路由器”开始调用基于该路由的特定控制器方法。因此，如果需要使用或获取一些数据的话，控制器需要与模型进行交互，而该模型也会与后台的数据库进行交互。

然后，一旦控制器获得了返回数据，它就需要加载一个视图。而具体的操作过程是：它将数据发送到视图，并由模板引擎来进行处理。

最后，一旦后台操作完成，控制器将把视图发送回浏览器，以供用户查看。

结论

综上所述，我们可以这样来理解MVC架构：模型是某种数据结构，控制器是流量控制器的一种形式，而视图则是用户看到并与之交互的部分。大家各司其职，让程序分工明确、条理清楚。

【51CTO译稿，合作站点转载请注明原文译者和出处为51CTO.com】