A Swing Architecture Overview（一）

大多swing开发人员现在都知道swing的组件采用的是模型-与-视图分离的设计，也有大量的swing使用者撰文陈述swing是基于"改良的MVC（模型-视图-控制者）结构"。

但是在此之前对于swing组件是怎么设计的，它们的各部分是如何组合到一块的都描述的不是很准确。

直到这篇swing组件设计白皮书文章的发表之后才让事情真相大白。本文对swing的改良的MVC架构做了一个很全面的技术概述，同时也对很多关于swing 组件架构的其它方面的技术也做了概述。

这篇文档对swing组件的架构做一个技术概论。详细来说，它具体包括以下几个领域：

• 设计目标
• MVC 的来源
• 可分离模型架构
• 可拔插感官架构

设计目标

Swing项目的所有目标如下：

为java开发人员建立一套可扩展的GUI组件，以助其快速开发出强大的面向java的商用软件。

为达到此目的，swing开发组在项目初期建立了一套设计目标来制定最终的架构。这些指导要求swing必须：

1. 完全使用java来实现以保证跨平台性和易维护性。
2. 提供可以支持多感官的单一的API，这样用户和开发人员将不会被绑定到单一的感官上面。
3. 具有不需要在最上层使用API的模型驱动编程能力。
4. 遵循JavaBeans设计规范以保证组件能够获得集成开发工具的良好支持。
5. 让功能重叠的AWT APIs可以兼容，使得AWT为基础知识能够轻松过渡。

MVC的来源
Swing 结构的来源要追溯到SmallTalk的模型-视图-控制者（MVC）设计。MVC架构要求可视化的应用程序分为三个独立的部分：

• 模型代表应用软件的数据。
• 视图指数据的可视化展现。
• 控制者获得视图上用户的输入并把它送到模型里面做相应的改变。

早期，MVC对swing来说是一个合理的选择，因为它基本上能够满足在后来两者的约束下实现我们的前三个设计目标。 在开始的时候，swing原型遵循了传统的MVC分离式架构，每个组件都有独立的模型对象，并且可以通过代理它的感官实现来分离视图和控制者对象。

代理(The delegate)
我们很快发现这样分割在实际应用中工作的不是很好，因为一个组件的视图和控制者部分需要紧密的耦合在一起（比如，一般很难写出一个不知道视图细节的控制者）。所以我们将这两个实体捏合成一个单一的UI（用户接口）对象，如图所示：
（图中的UI代理对象有时被称为代理对象，或者UI代理，swing中的UI代理在本文的可拔插感官部分有更详细的描述，副标题为“UI代理”）。

如图所示，swing架构基本上是基于传统的MVC架构设计－但不是很严格。在swing的世界里，这种类MVC架构设计有时归类于模型可分离架构。

Swing的模型可分离设计和MVC架构设计一样把一个组件的模型部分当作一个单独的元件。但是swing把视图和控制者部分捏合到一块变成一个独立的UI（用户接口）对象。

到底是还是不是MVC架构？

一个值得注意的地方是作为一个应用软件开发人员，你应考虑一般的组件类（如： JButton，JTree等等）赋予给组件的视图/控制者的责任。

举例来说，双缓冲绘制的代码是在swing的JComponent类（大部分swing组件类的“母亲”）中实现的，然而渲染一个JButton的label的代码是在button的UI代理类中实现的。在前面的图中说明了这个微妙的（经常容易使人迷惑的）地方。

所以swing拥有比较浓的MVC血统。但是重申我们的MVC架构与传统的MVC架构之间具有两种截然不同的设计目的依然很重要。

• 首先，把模型从一个组件里面分离出来定义方便了swing里面的模型驱动编程。
• 第二，为一个组件的视图/控制者代理一些分离感官对象的责任的能力为swing的可拔插感官架构提供了基础。

虽然这两个概念因为MVC设计而产生联系，从开发人员的角度来看它们可能被认为有点交叉。本文接下来部分将会对所有的这些机制做非常详细的描述。


来源：
http://www.blogjava.net/azure/archive/2007/05/05/115441.html
http://java.sun.com/products/jfc/tsc/articles/architecture/ui_install/index.html