代码之家 › 专栏 › 技术社区 › Guillaume

JavaSwing:保持事件处理的可维护性

events swing java

Guillaume · 技术社区 · 15 年前

在我当前的项目中,我们正在为swing客户机使用以下模式:

业务对象(POJO)<-->(映射)<-->表示模型(支持属性更改的POJO)<-->(绑定)<-->查看组件

一切都很好,按照我们期望的方式运作。

但是,当观点开始增长时,我们会遇到这些问题:

许多事件被触发,导致级联事件。对字段的一次更新可能会导致数十次后续属性更新
当对话框的复杂性增加时,侦听器的数量也会随之增加,并且代码开始变得混乱和难以理解。

在第一个答案后编辑:

如果值没有变化,我们不会触发事件。
如果不需要侦听器,我们就不添加侦听器。

我们的屏幕有非常复杂的规则,并且需要其他相关面板的通知。因此我们有很多有用的监听器,一个用户的更改可以触发许多底层事件。

将表示模型与业务模型绑定的想法对我们不太好:我们在映射过程中执行一些代码。

我正在寻找关于构建可维护的swing应用程序的指南、建议、最佳实践等,特别是在事件管理方面。

3 回复 | 直到 15 年前

Riduidel 15 年前

有很多方法可以减少发送的事件数。

没有更改时不要传播事件。这方面的一个典型例子是编写setter触发propertyChangeEvent的惯用方法(见下文),但对于手动触发的所有类型的事件都是如此。


    public void setMyField(Object newValue) {
        Object oldValue = myField;
            if((oldValue==null && newValue!=null) || (oldValue!=null && !oldValue.equals(newValue))) {
                myField = newValue;
                propertyChangeSupport.firePropertyChange("myField", oldValue, newValue);
            }
        }
    }

只在您开始感兴趣时注册为事件侦听器,并在您停止感兴趣时注销。事实上,作为侦听器,即使它不需要任何操作,也会强制jvm调用用于事件传播的各种方法。不做侦听器将避免所有这些调用,并使应用程序简单得多。
考虑通过直接实例化增加的pojo来将pojo替换为增加的pojo映射。或者,更简单的说:用PrimeTyeEngEvter处理能力制作POJO身份验证Java bean。为了使它们易于持久化,一个简单的解决方案是,一旦“重新水化”,或者从持久层加载,就添加一个持久化更新器机制作为propertyChangeListener。这样,当更新pojo时,持久层得到通知,并透明地更新db中的对象。

所有这些都是非常简单的建议,只需要大量的散堆,以确保事件只在正确的时间触发,并为正确的听众。

Tom Hawtin - tackline 15 年前

我建议每个模型使用一个事件操作。不要试图把它分解成绝望的田野 ProtpertyChangeListener . 使用 ChangeListener 或者你自己的同类产品。(老实说,事件参数没有帮助。)可能将“property”类型更改为可侦听对象,而不是侦听复合对象。

Community Mohan Dere 9 年前

这个 EventListenerList 大多数swing组件使用的方案相当轻量级。在决定新的体系结构之前,一定要分析代码。除了 usual choices ,另一种监视事件通信量的有趣方法是 EventQueue 子类 example .