面向交互的体系结构的主要目标是将用户的交互与数据抽象和业务数据处理分开。面向交互的软件架构将系统分解为三个主要分区：

• 数据模块-数据模块提供数据抽象和所有业务逻辑。

• 控制模块-控制模块识别控制流程和系统配置动作。

• 视图呈现模块-视图呈现模块负责数据输出的视觉或音频呈现，它还提供了用于用户输入的界面。

面向交互的体系结构具有两种主要样式-模型视图控制器(MVC)和表示抽象控制(PAC)。 MVC和PAC都建议分解三个组件，并用于交互式应用程序，例如具有多个对话和用户交互的Web应用程序。他们的控制和组织流程不同。 PAC是基于代理的层次结构，但是MVC没有明确的层次结构。

模型视图控制器(MVC)

MVC将给定的软件应用程序分解为三个相互联系的部分，这些部分有助于将信息的内部表示形式与提供给用户或从用户接受的信息中分离出来。

模型

模型是MVC的核心组件，它直接管理应用程序的数据，逻辑和约束。它由数据组件组成，这些组件维护原始应用程序数据和接口的应用程序逻辑。

• 它是一个独立的用户界面，捕获应用程序问题域的行为。

• 它是特定于领域的软件模拟或应用程序中央结构的实现。

• 当状态发生变化时，它会通知其关联的视图以产生更新的输出，并向控制器发出更改可用命令集的通知。

视图

视图可用于以图形形式表示任何信息输出，例如图表或图表。它由表示组件组成，这些组件提供数据的可视表示

• 查看其模型中的请求信息，并向用户生成输出表示。

• 可以使用同一信息的多种视图，例如用于管理的条形图和用于会计的表格视图。

控制者

控制器接受输入并将其转换为模型或视图的命令。它由输入处理组件组成，这些组件通过修改模型来处理来自用户的输入。

• 它充当关联的模型和视图与输入设备之间的接口。

• 它可以向模型发送命令以更新模型的状态，并向其关联的视图发送命令以更改视图的模型表示。

MVC-我

它是MVC体系结构的简单版本，其中系统分为两个子系统-

• Controller-View -Controller-view充当输入/输出接口，并且处理完成。

• 模型-模型提供所有数据和域服务。

MVC-I架构

模型模块将任何数据更改通知给控制器视图模块，以便任何图形数据显示都将相应更改。控制器还对更改采取适当的措施。

可以按照订阅通知的模式(如上图所示)设计控制器视图与模型之间的连接，由此控制器视图订阅模型，模型将任何更改通知给控制器视图。

MVC-II

MVC-II是MVC-I体系结构的增强，其中视图模块和控制器模块是分开的。通过提供数据库支持的所有核心功能和数据，模型模块在MVC-1中起着积极的作用。

视图模块在控制器模块接受输入请求，验证输入数据，启动模型，视图，它们的连接以及调度任务的同时显示数据。

MVC-II架构

MVC应用

对于单个数据模型需要多个视图且易于插入新的或更改接口视图的交互式应用程序，MVC应用程序非常有效。

MVC应用程序适用于模块之间有明确划分的应用程序，因此可以分配不同的专业人员来同时处理此类应用程序的不同方面。

好处

• 有许多可用的MVC供应商框架工具包。

• 多个视图与同一数据模型同步。

• 易于插入新的或替换的界面视图。

• 用于应用程序开发，其中图形专家，编程专家和数据库开发专家正在设计的项目团队中工作。

缺点

• 不适合面向代理的应用程序，例如交互式移动和机器人应用程序。

• 基于同一数据模型的多对控制器和视图使任何数据模型更改都变得昂贵。

• 在某些情况下，视图和控制器之间的划分不清楚。

表示抽象控制(PAC)

在PAC中，系统被安排为许多合作代理(三合会)的层次结构。它是从MVC开发的，除了支持交互式需求外，还支持多个代理的应用程序需求。

每个代理都有三个组成部分-

• 表示组件-格式化数据的视觉和音频表示。

• 抽象组件-检索和处理数据。

• 控制组件-处理诸如其他两个组件之间的控制流和通信之类的任务。

从表示模块就像MVC的视图模块的意义上来说，PAC体系结构类似于MVC。抽象模块看起来像MVC的模型模块，控制模块就像MVC的控制器模块，但是它们的控制和组织流程不同。

每个代理中的抽象组件和表示组件之间没有直接连接。每个代理中的控制组件负责与其他代理进行通信。

下图显示了PAC设计中单个代理的框图。

具有多个代理的PAC

在由多个代理组成的PAC中，顶级代理提供核心数据和业务逻辑。底层代理定义详细的特定数据和表示。中级或中级代理充当低级代理的协调者。

• 每个业务代表都有自己特定的分配工作。

• 对于某些中级代理，不需要交互式演示，因此它们没有演示组件。

• 所有代理程序都需要控制组件，所有代理程序通过它们相互通信。

下图显示了参与PAC的多个Agent。

应用领域

• 对于交互式系统有效，在该系统中，系统可以按层次结构分解为许多协作代理。

• 当预期代理之间的耦合松散，以使代理上的更改不会影响其他代理时，此选项有效。

• 对于所有代理都分散分布并且每个代理都有自己的功能(具有数据和交互界面)的分布式系统有效。

• 适用于具有丰富GUI组件的应用程序，其中每个组件都保留自己的当前数据和交互式界面，并且需要与其他组件进行通信。

好处

• 支持多任务和多视图

• 支持代理可重用性和可扩展性

• 易于插入新代理或更改现有代理

• 当多个代理在不同线程或不同设备或计算机中并行运行时，支持并发

缺点

• 由于表示和抽象之间的控制桥以及代理之间的控件通信而造成的开销。

• 由于代理之间的耦合松散和高度独立，因此难以确定合适的代理数量。

• 由于代理之间的通信仅在代理的控件之间进行，因此每个代理中的控件将表示和抽象完全分离会产生开发复杂性