用户界面软件05

已知应用

几乎所有的流行的用户界面架构都使用这种模式。我在这里举三个例子：

1. Seeheim 用户界面架构的特点是有一个应用核心的领域层和一个用户界面层。后者
被分为两层，叫做表示层和对话控制层。因为这个架构和面向事务系统有渊源，没有从应用
核心到用户界面的回调机制。

2. 可能最流行的例子是模型－视图－控制器（MVC）架构[BMR+96]。视图和控制器
类构成用户界面层，而模型类构成领域层。视图和控制器可以发送特定消息给模型，反之则
不行。一个观察者（Observer）提供从模型到视图的回调机制。

IBM Visual Age for SmallTalk 允许程序员用部件（parts）构成应用程序，这个架构中有可视
化部件（Visual Parts），例如菜单，树状图，窗体，还有非可视化部件包装了一般的SmallTalk 类。

有条理地使用的话，可视化部件对应于用户界面层，而非可视化部件则对应于领域层。
参考 [BMR+96]对层状架构进行了深入的讨论。

子系统架构

在你决定使用用户界面层（User Interface Layer）后，工作才刚刚开头。牢记分层的主要目的：封装复杂的用户界面。所以，通常情况下，将整个用户界面层实现为一块并不是一个好办法。因此，下一步就是寻找子系统。

有四个子系统组成了整个架构：分离转换（Separate Transformation），配件模型（Widget Model），域层存取（Domain Layer Access），以及上下文支持（Context Support）。你几乎可以在每个用户界面架构里面找到Separate Transformation, Widget Model, Domain Layer Access 的影子，但Context Support 则视环境而言。

分离转换（Separate Transformation）

概要将信息显示在屏幕上和处理用户的动作是两件复杂的不同任务。所以将用户动作到领域层调
用的转换，和同领域信息到屏幕信息的转换分离。

上下文在你决定使用一个用户界面层（User Interface Layer）之后，工作才刚刚开始。你得定义用户界面的详细结构，通常输入和输出会很清楚地分开考虑。特别是当你使用直接操作，和
Tool-Material 隐喻时。显示信息和处理操作都是非常复杂的。因此……

问题如何将输入和输出过程分配给子系统？

要得到一个解决方案，你需考虑几个约束：

约束可视化和操作是复杂的任务，但是它们是紧紧联系在一起的。

让我们来看一下一个新闻阅读器在不同线索下的树状图。它由几个不同的图形元素，如线条，
图标等构成。所有的这些图形元素显示领域层的信息，比如状态等。对这些表示的控制需要一些
很棒的复杂的软件。除了外观之外，这个窗体还要能用多种方式阅读帖子，进行标记，回帖，或者保存。用户使用弹出菜单或下拉菜单，以及拖放技术来完成大部分的动作。控制这些动作，以
及将这些动作转到领域层也是复杂的任务。所以，将可视化和操作分离的话，很有吸引力。不过，
这个办法行得通吗？两部分都相互紧紧地联系在一起：首先，它们都在同样的领域层对象上，比
如一个新闻帖子；另外，同一界面实体可能同时代表可视化和操作。比如每个作者名字前面的小
菱形，在可视化方面表示目前我还没有阅读过这个帖子（尽管早应该读了），如果你点击一下它，
阅读器就将相应的帖子标记为已读，这很明显是是一个操作任务。