MVC: события изменения свойств для вложенных моделей - PullRequest
0 голосов
/ 22 октября 2010

Я создаю приложение с графическим интерфейсом и стараюсь придерживаться принципа MVC настолько хорошо, насколько могу.

Поэтому моя модель запускает PropertyChangeEvent s с помощью PropertyChangeSupport, поэтому графический интерфейс знает, чтообновлять, когда.

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

Простой пример:

public class MainModel {
    private int someData;
    private List<Stuff> stuffList;
    // imagine PropertyChangeSupport and appropriate getters/setters
    // for both MainModel and Stuff
}

Теперь и MainModel, и Stuff имеют PropertyChangeSupport.Если кто-то слушает события, запущенные с MainModel, он получает изменения someData и от добавления / удаления в / из списка stuffList.

Но что, если кто-то хочет получить события от изменений, внесенных вотдельные элементы stuffList?Есть две возможности:

  1. Наблюдатель должен получить список Stuff элементов и зарегистрироваться в качестве слушателя каждого элемента в отдельности.
  2. Основная модель регистрирует себя в качестве слушателяк элементам stuffList при их добавлении и перенаправлении этих событий слушателю основной модели.

Вот как это выглядит при первом подходе:

mainModelInstance.addListener("new stuff element", new PropertyChangeListener() {
    public void propertyChanged(PropertyChangeEvent evt) {
        Stuff s = (Stuff) evt.getNewValue();
        s.addListener( // ... and so on
        );
    }
});

Я думаю, что 1. имеет преимущество в том, что поддерживает чистоту и тупость модели, но приводит к дублированию кода (многие элементы пользовательского интерфейса должны прослушивать изменения в stuffList и динамически добавлять себя в новые элементы Stuff, см. Выше).В 2. наоборот: клиентский код не такой грязный, но модель действует частично как слушатель, который почему-то не чувствует себя правильным .Вот почему я сейчас использую первый подход.

Что вы думаете?Может быть, я слишком резок с собой и 2. все в порядке.Или, может быть, есть совершенно другой (и лучший) способ?

1 Ответ

1 голос
/ 07 марта 2011

В течение как минимум 20 лет я программировал модели MVC, соблюдая другие модели (например, для выполнения того, что сейчас называется паттернами MVP [resenter] или MVVM), и вот некоторые эвристики, которые я бы предложил ...

(1) Представления и контроллеры являются иерархическими, и обработка событий в GUI уже давно распознала это, позволяя слушателям событий прослушивать на разных уровнях иерархии (например, непосредственно на уровне кнопок или на уровне всей веб-страницы). Каждое событие указывает наиболее конкретный компонент, связанный с событием, даже если прослушивался контейнер более высокого уровня (также наблюдаемый). Говорят, что события «всплывают».

(2) Модели могут быть в равной степени иерархическими. Генерируемое моделью событие «обновление» также может использовать ту же технику, что и выше, указав в событии наиболее конкретную «внутреннюю модель», связанную с событием обновления, но позволяя наблюдать на уровне «внешней» составной модели. События обновления наблюдателя могут «всплывать».

(3) Существует общая парадигма для иерархических моделей ... электронная таблица. Каждая ячейка - это модель, которая наблюдает за другими моделями / ячейками, указанными в ее формуле.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...