Java Desktop 的再介绍”强调了今年的 JavaOne 大会。对于那些抱怨 Swing 太慢、太难使用、界面太难看的开发人员来说，Swing 和 GUI 开发所做的更新努力，并没有带来什么受人欢迎的好消息。如果您最近没有用过 Swing，那么您会很高兴听到其中的许多问题已经得到解决。Swing 被重新设计，它能执行得更好，并能更好地利用 Java 2D API。Swing 的开发者在 1.4 版甚至最新发布的 5.0 版中提高了外观支持。Swing 从没像现在这么好过。
如果以前曾经用过 JTable，那么您可能也同时被迫使用了 TableModel。您可能还注意到，每个 TableModel 中的所有代码，与其他 TableModel 中的代码几乎是一样的，在编译的 Java 类中，有差异的代码实际上是不存在的。
本文将分析JTable和TableModel目前的设计方法，说明这种设计的不足，展示为什么它没有实现模型-视图-控制器(MVC)模式的真正目标。您将看到框架和构成 TMF 框架的代码 —— 我以前编写的代码与最常用的开放源代码项目的组合。使用该框架，开发人员可以把 TableModel 的大小从数百行代码减少到只有区区一行，并把重要的表信息放在外部 XML 文件中。在读完本文之后，只使用如下所示的一行代码，您就可以管理您的 JTable 数据：
- TableUtilities.setViewToModel("tableconfig.xml", "My Table",
- myJTable, CollectionUtilities.observableList(myData));
JTable和TableModel存在的 MVC 问题
MVC 已经成为非常流行的 UI 设计模式，因为它把业务逻辑清晰地从数据的视图中分离了出来。Struts 是 MVC 在 Web 上应用的一个非常好的例子。最初，Swing 最大的一个卖点是它采用了 MVC，将视图从模型中分离了出来，代码背后的想法是：代码的模块化程度足够高，所以，不用修改模型中的任何代码，就可以分离出视图。我想，任何用过JTable和TableModel的人都会发笑，告诉您这是绝对不可能的。使用 MVC 设计模式的理想情况是，在开发人员用 JList 或 JComboBox 替换 JTable 时，可以不用修改表示数据的模式中的代码。但是，在 Swing 中做不到这点。
Swing 使得把 JTable、 JList 和 JComboBox 热交换到应用程序中成为不可能，即使所有这三个组件都是用来为相同的数据模型提供视图。对于 Swing 中的 MVC 设计，这是一个严重的不足。如果您想为 JTable 交换 JList，就必须重写视图背后的全部代码，才能实现该交换。
JTable和TableModel的另一个 MVC 缺陷是：模型变化的时候，视图不会更新自身。开发人员必须保持对模型的引用，并调用一个函数，这样模型才会告诉视图对自身进行更新;但是，理想的情况应当是：不需要任何额外的代码，就能实现自动更新。
最后，JTable和TableModel 组件设计的问题是，它们彼此之间缠杂得过于密切。如果您修改了 JTable 中的代码，那么您需要确保您没有破坏负责处理的 TableModel，反之亦然。对于一个被认为是在模块化基础上建立的设计模式来说，目前的实现显然是一种存在过多依赖关系的设计。
TMF 框架更好地遵循了 MVC 的目标，它把 JTable 中视图和模型的工作更加清晰地分离开来。虽然它还没有达到让组件能够热切换的更高目标，但是它已经在正确方向上迈出了一步。
【编辑推荐】
