Java Swing : keeping the event handling maintanable

Question

在我当前的项目中，我们为 Swing 客户端使用以下模式:

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

一切都很好，并且按照我们期望的方式运行。

但是，当 View 开始增长时，我们会遇到这些问题:

1. 许多事件被触发，导致级联事件。一个字段的一次更新可能会导致后续数十次属性更新
2. 当对话复杂性增加时，监听器的数量也会增加，代码开始变得困惑且难以理解。

<小时/>

第一个答案后编辑:

• 如果值没有变化，我们不会触发事件。
• 如果不需要监听器，我们不会添加它们。

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

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

<小时/>

我正在寻找有关构建可维护的 Swing 应用程序的指南、建议、最佳实践等，尤其是事件管理方面的指南、建议、最佳实践等。

Answer 1

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

1. 没有变化时不要传播事件。这方面的一个典型例子是 ios，它是编写触发 PropertyChangeEvent 的 setter 的惯用方式(见下文)，但对于手动触发的所有类型的事件都是如此。

    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 映射。或者，说得更简单:使您的 POJO 具有 PropertyChangeEvent 处理能力的真正的 java beans。为了使它们能够轻松持久化，一个简单的解决方案是，一旦“重新水合”或从持久层加载，添加持久更新器机制作为 PropertyChangeListener。这样，当 POJO 更新时，持久层会收到通知，并透明地更新 DB 中的对象。

所有这些都是相当简单的建议，只需要大量的纪律，以确保事件仅在正确的时间针对正确的听众触发。