MVC架构介绍
每个程序员都知道的最流行的应用程序架构是MVC。MVC 代表模型-视图-控制器。
这与其说是应用程序的架构，不如说是应用程序组件的架构，但我们稍后会回到这个细微差别。什么是 MVC？
MVC 是一种将应用程序数据和控制逻辑分离为三个独立组件（模型、视图和控制器）的方案，以便每个组件都可以独立修改。
- 模型（Model）通过改变其状态来提供数据并响应控制器命令。
- 视图负责向用户显示模型数据以响应模型更改。
- 控制器（Controller）解释用户的动作，通知模型需要改变。
该模型是在 1978 (!) 年发明的。是的，正确的软件架构问题在 50 年前就已经存在。以下是原始图表描述此模型的方式：
该模型提供数据和使用它们的方法：查询数据库、检查正确性。该模型独立于视图（不知道如何呈现数据）和控制器（没有用户交互点），提供对数据的访问和管理。
该模型的构建方式是通过改变其状态来响应请求，并且可以内置“观察者”的通知。由于独立于视觉表示，模型可以对一个“模型”有多个不同的表示。
视图负责从模型中获取所需的数据并将其发送给用户。该视图不处理用户输入。
控制器提供用户和系统之间的“通信”。控制和引导数据从用户到系统，反之亦然。使用模型和视图来实现所需的操作。
该模型在过去几十年中有所发展，这一事实存在一定的困难。也就是说，名称保持不变，但零件的用途开始发生变化。
Web 上的 MVC 架构
MVC 设计模式背后的思想非常简单：我们需要明确区分应用程序中不同行为的责任：
模型——数据处理和应用逻辑。
看法——以任何支持的格式向用户提供数据。
控制器- 处理用户请求并调用适当的资源。
该应用程序分为三个主要组件，每个组件负责不同的任务。让我们通过一个示例来更深入地了解客户端-服务器应用程序的组件。
控制器
用户在浏览器中单击页面上的各种元素，结果浏览器发送各种 HTTP 请求：GET、POST 或其他。控制器可以包括在页面内工作的浏览器和 JS 代码。
在这种情况下，控制器的主要功能是调用必要对象的方法，管理对资源的访问以执行用户指定的任务。通常，控制器为任务调用适当的模型并选择适当的视图。
模型
广义上的模型是数据和用于处理数据的规则——它们共同构成了应用程序的业务逻辑。设计应用程序总是从构建它所操作的对象的模型开始。
假设我们有一家卖书的在线商店，那么一个人只是应用程序用户还是一本书的作者？在模型设计期间必须解决这些重要问题。
此外还有规则集：可以做什么，不能做什么，哪些数据集可以接受，哪些不可以。一本书可以没有作者吗？没有书的作者呢？用户的出生日期是否可以在 300 年等等。
该模型为控制器提供了用户请求的数据（消息、书页、图片等）的视图。无论我们想如何将其呈现给用户，数据模型都是相同的。因此，我们选择任何可用的视图来显示数据。
该模型包含我们应用程序逻辑中最重要的部分，即解决我们正在处理的问题（论坛、商店、银行等）的逻辑。控制器主要包含应用程序本身的组织逻辑（就像您的项目经理一样）。
看法
视图提供了多种方式来表示从模型接收到的数据。它可以是一个填充有数据的模板。可以有几种不同的视图，控制器选择最适合当前情况的一种。
Web 应用程序通常由一组控制器、模型和视图组成。控制器只能在后端，但当其逻辑也分布在前端时，也可以有多个控制器的变体。这种方法的一个很好的例子是任何移动应用程序。
网络上的 MVC 示例
假设您需要开发一家销售书籍的在线商店。用户可以执行以下操作：查看书籍、注册、购买、将项目添加到当前订单、标记他喜欢的书籍并购买。
您的应用程序应该有一个负责所有业务逻辑的模型。您还需要一个控制器来处理所有用户操作并将它们转换为来自业务逻辑的方法调用。但是，一个控制器方法可以调用许多不同的模型方法。
您还需要视图集：书籍列表、关于一本书的信息、购物车、订单列表。Web 应用程序的每个页面实际上都是一个单独的视图，向用户显示模型的某个方面。
让我们看看如果用户打开书店推荐书籍列表来查看书名会发生什么。整个动作序列可以用 6 个步骤的形式描述：
脚步：
- 用户点击“推荐”链接，浏览器向/books/recommendations发送请求。
- 控制器检查请求：用户必须登录。或者我们应该为未登录的用户收集书籍。然后控制器调用模型并要求它返回推荐给用户 N 的书籍列表。
- 该模型访问数据库，从那里检索有关书籍的信息：当前流行的书籍、用户购买的书籍、他的朋友购买的书籍、他的愿望清单中的书籍。基于这些数据，模型构建了一个包含 10 本推荐书籍的列表，并将它们返回给控制器。
- 控制器收到推荐书籍列表并查看它。在这个阶段，控制器做出决定！如果书籍很少或列表完全为空，则它会为未登录的用户请求书籍列表。如果现在正在进行促销，则控制器可以将促销书籍添加到列表中。
- 控制器决定向用户显示哪个页面。它可以是一个错误页面，一个包含书籍列表的页面，一个祝贺用户已成为百万分之一访问者的页面。
- 服务器向客户端提供控制器选择的页面（视图）。它填充了必要的数据（用户名、书籍列表）并发送给客户端。
- 客户端接收页面并将其显示给用户。
这种方法有什么好处？
我们从使用 MVC 概念中获得的最明显的优势是表示逻辑（用户界面）和应用程序逻辑（后端）的明确分离。
第二个优势是将服务器部分分为两部分：智能模型（执行器）和控制器（决策中心）。
在前面的例子中，有一段时间控制器可以从模型中收到一个空的推荐书籍列表，并决定如何处理它。理论上，可以将此逻辑直接放入模型中。
首先，在请求推荐书籍时，如果列表为空，模型将决定做什么。然后我将不得不在同一个地方添加代码，如果现在正在进行促销该怎么办，然后有更多不同的选择。
后来发现店主想看看没有促销的情况下用户的页面会是什么样子，反之亦然，现在没有促销，但他想看看以后的促销会如何显示。并且没有为此的方法。因此，决定将决策中心（控制器）与业务逻辑（模型）分开。
除了将视图与应用程序逻辑隔离之外，MVC 概念还大大降低了大型应用程序的复杂性。代码更加结构化，更易于维护、测试和重用解决方案。
了解 MVC 的概念，作为开发人员，您会意识到需要在何处添加对图书列表进行排序：
- 在数据库查询级别。
- 在业务逻辑（模型）级别。
- 在业务逻辑层（控制器）。
- 在视图中 - 在客户端。
这不是一个修辞问题。现在，想一想您需要在何处以及为何需要添加用于对图书列表进行排序的代码。
经典 MVC 模型
MVC 组件之间的交互在 Web 应用程序和移动应用程序中的实现方式不同。这是因为 Web 应用程序是短暂的，处理一个用户请求并退出，而移动应用程序处理许多请求而无需重新启动。
Web 应用程序通常使用“被动”模型，而移动应用程序使用“主动”模型。与被动模型不同，主动模型允许您订阅和接收其中更改的通知。Web 应用程序不需要这样做。
这是各种模型中组件交互的样子：
移动应用程序（主动模型）主动使用事件和事件订阅机制。通过这种方法，视图 ( view ) 订阅模型更改。然后，当某些事件发生时（例如，用户单击按钮），将调用控制器。它还为模型提供了更改数据的命令。
如果某些数据已更改，则模型会生成有关更改此数据的事件。所有订阅此事件的视图（更改此特定数据很重要）都会收到此事件并更新其界面中的数据。
在 Web 应用程序中，事物的组织方式略有不同。主要的技术区别是客户端不能主动接收服务器端的消息。
因此，Web 应用程序中的控制器通常不会向视图发送任何消息，而是给客户端一个新页面，从技术上讲，这是一个新视图甚至是一个新的客户端应用程序（如果一个页面对另一个页面一无所知） .
目前，使用以下方法可以部分解决此问题：
- 定期轮询服务器以了解重要数据的更改（每分钟一次或更长时间）。
- WebSockets 允许客户端订阅服务器消息。
- 来自服务器端的 Web 推送通知。
- HTTP/2 协议允许服务器发起向客户端发送消息。