architecture - PAC 和 MVC 架构之间的主要区别

Question

在 PVC 架构中，每个系统（或代理）是否应该在其中包含表示、抽象、控制组件？它与 MVC 架构有何不同？我对这两者更感到困惑。

有人可以帮我举个例子吗？

标签： architecture

Answer 1

模块化设计 模块化设计是软件工程中公认的好事。与一般科学一样，将问题分解成更小、更小的部分更容易解决。它还允许不同的人解决问题的不同部分，并且最终仍然可以正常工作。然后每个组件都是自包含的，只要不同组件之间的接口保持不变，就可以根据需要扩展甚至删除和重写，而不会造成混乱。

我应该注意，模块化设计与基于插件的设计不同，这是许多开源项目使用的。Drupal“模块”实际上是插件。Linux 内核、Apache、Eclipse 和许多其他具有“可加载模块”的知名项目都是基于插件的架构。基于插件的架构与模块化设计并非不兼容，实际上可以很好地补充它，但我离题了......

大多数软件架构模式都基于模块化设计是一件好事的想法，而不是根据定义。系统有很多架构模式，具体取决于它们应该做什么。对于交互系统，通常的组件分解是“显示组件”、“数据存储组件”和“业务逻辑”。

MVC 最常见的交互式系统架构是模型-视图-控制器，或 MVC。大多数优秀的桌面应用程序都使用 MVC 或其变体，有时将控制器部分合并到视图中。在 MVC 中，正如链接另一端的漂亮图片所示，Model 保存数据，View 是用户看到的部分，而 Controller 是业务逻辑的中介。看起来很合理，对吧？现在仔细看看。

在 MVC 中，视图组件可以直接访问模型。除非数据发生实际变化，否则控制器本身不会进入画面。简单地读取和显示数据完全由 View 组件本身完成。因此，一个系统可以同时激活多个 View 组件，所有组件都以各种不同的方式读取和显示数据，甚至在不同的系统或不同的语言或不同的模式下（GUI、文本和 Web）。然而，另一方面，这意味着 View 组件中必须有一些相当复杂的逻辑。它需要知道如何从 Model 中拉取数据，这意味着它需要知道数据结构是什么（或者至少是 Model 前面的丰富 API）。它需要能够使用自己的事件循环来处理用户交互。

好吧，这排除了大多数可能的 web-MVC 设置。此类系统最常见的呼声之一是“从 HTML 中获取数据库内容”。相反，一切都通过智能控制器处理，该控制器使用模板层来呈现和显示输出。这不一定是一个糟糕的设计，但它不是 MVC。如果显示组件没有对数据存储的直接、随机访问、拉取访问，则它不是 MVC。

PAC 一种较少公开但仍被广泛使用的架构是 Presentation-Abstraction-Control，或 PAC。MVC 和 PAC 之间的两个主要区别是，在 PAC 中，表示组件是“哑的”，而所有智能都驻留在控制器中，而 PAC 是分层的。再次，看看漂亮的图片。

您会注意到 Presentation 和 Abstraction 组件从不相互交流。控制器接受输入，而不是显示组件。Controller 拥有所有的业务逻辑和路由信息。Presentation 组件本质上只是一个过滤器，它获取控制器通过它推送的原始数据并将其呈现为 HTML（或 WML，或 XML，或文本，或图形监控系统中的图标，或其他）。它只是一个模板系统。

PAC 架构的经典示例是空中交通管制系统。一个 PAC 代理从雷达系统获取有关传入 747 位置的输入，并使用 Presentation 组件在画布（屏幕）上绘制该光点的图片。另一位特工独立接受有关正在起飞的 DC-10 的输入，并将该光点也绘制到画布上。还有一个接收天气数据并绘制云，而另一个跟踪来袭的敌方轰炸机并绘制红色光点。（呃，等等……）