Architecture PAC和MVC架构的主要区别

在PVC体系结构中，每个系统（或代理）是否应该具有表示、抽象和控制组件？它与MVC体系结构有何不同？我更不明白这两者之间的区别

有人能帮我举个例子吗？

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

我应该注意到，模块化设计与基于插件的设计不同，这是许多开源项目所使用的。Drupal“模块”实际上是插件。Linux内核、Apache、Eclipse和许多其他具有“可加载模块”的引人注目的项目都是基于插件的体系结构。基于插件的体系结构与模块化设计并不是不兼容的，事实上是对模块化设计的很好补充，但我离题了

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

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

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

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

PAC 一种不太为人所知但仍然广泛使用的体系结构是表示抽象控制（Presentation Abstraction Control，简称PAC）。MVC和PAC之间的两个主要区别是，在PAC中，表示组件是“哑”的，而所有智能都驻留在控制器中，PAC是分层的。再一次，看看这幅美丽的图画

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

PAC体系结构的经典示例是空中交通控制系统。一个PAC代理从雷达系统获取输入信息，了解来袭747的位置，并使用演示组件在画布（屏幕）上绘制该光点的图片。另一个代理独立地获取关于正在起飞的DC-10的输入，并将该光点绘制到画布上。还有一个接收天气数据并绘制云彩，而另一个跟踪来袭的敌人轰炸机并绘制红色光点。（呃，等等…）模块化设计 模块化设计是软件工程中公认的好东西（tm）。正如在一般科学中一样，将问题分解成更小、更容易解决的部分。它还允许不同的人解决问题的不同部分，并且最终仍然能够正确地工作。然后，每个组件都是自包含的，只要不同组件之间的接口保持不变，就可以根据需要进行扩展甚至删除和重写，而不会造成混乱

我应该注意到，模块化设计与基于插件的设计不同，这是许多开源项目所使用的。Drupal“模块”实际上是插件。Linux内核、Apache、Eclipse和许多其他具有“可加载模块”的引人注目的项目都是基于插件的体系结构。基于插件的体系结构与模块化设计并不是不兼容的，事实上是对模块化设计的很好补充，但我离题了

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

MVC 最常见的交互系统体系结构是模型-视图-控制器