Java Swing: поддержание управляемости событий

Question

В моем текущем проекте мы используем для нашего клиента Swing следующие шаблоны:

Бизнес-объект (POJO) <-> (отображение) <-> Модель представления (POJO с поддержкой изменения свойств) <-> (привязка) <-> просмотреть компоненты

Все хорошо и работает так, как мы ожидаем, что они будут себя вести.

НО, мы приветствуем те проблемы, когда вид начинает расти:

1. Многие события запускаются, что приводит к каскадным событиям. Одно обновление поля может привести к десяткам последующих обновлений свойства
2. Когда сложность диалога возрастает, число слушателей также увеличивается, и код начинает быть грязным и трудным для понимания.

---

Редактировать после первого ответа:

• Мы не запускаем событие, если нет изменений по значению.
• Мы не добавляем слушателя, если он нам не нужен.

У нас есть экран с очень сложными правилами и с необходимостью уведомления от других связанных панелей. Таким образом, у нас есть много полезных слушателей, и одно изменение пользователя может вызвать много основных событий.

Идея связать модель представления с бизнес-моделью для нас не очень хороша: мы выполняем некоторый код в процессе отображения.

---

Я ищу руководства, советы, рекомендации и т. Д. По созданию поддерживаемого приложения Swing, особенно для управления событиями.

Answer 1

Я предлагаю одно действие для каждой модели. Не пытайтесь разбить его на поля с безнадежным ProtpertyChangeListener. Используйте ChangeListener или ваш собственный эквивалент. (Честно говоря, аргумент события бесполезен.) Возможно, измените тип «свойства», чтобы он был объектом прослушивания, а не прослушиванием составного объекта.

Answer 2

Существует множество способов уменьшить количество отправляемых событий.

1. Не распространять событие, если нет изменений. Типичный пример для этого - идиоматический способ написания сеттера, запускающего 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);
            }
        }
    }

2. Зарегистрируйтесь в качестве прослушивателя событий только тогда, когда вы начнете интересоваться, и отмените регистрацию, как только вы перестанете интересоваться. Действительно, будучи прослушивателем, даже если это бездействие, заставляет JVm вызывать различные методы, используемые для распространения событий. Не будучи слушателем, вы избежите всех этих вызовов и значительно упростите приложение.

3. Подумайте о замене вашего POJO на увеличенное отображение POJO путем прямого создания увеличенного POJO. или, проще говоря: сделайте ваши POJO-аутентичные Java-бины с возможностями обработки PropertyChangeEvent. Чтобы их можно было легко сохранить, простое решение, после «регидратации» или загрузки со слоя постоянства, добавляет механизм обновления постоянства как PropertyChangeListener. Таким образом, при обновлении POJO слой постоянства получает уведомление и прозрачно обновляет объект в БД.

Все это довольно простые советы, требующие только большой дозы дисциплины, чтобы обеспечить запуск событий только в нужное время и для нужных слушателей.

Answer 3

Схема EventListenerList, используемая большинством компонентов Swing, довольно легкая. Обязательно профилируйте код, прежде чем принимать решение о новой архитектуре. В дополнение к обычным вариантам в этом подклассе EventQueue предлагается .

другой интересный подход к мониторингу трафика событий