Java MVC: обновление представления, которое наблюдает за несколькими моделями

#java #model-view-controller #swing #design-patterns

#java #model-view-controller #swing #шаблоны проектирования

Вопрос:

В моем приложении MVC я отображаю диаграмму, используя Swing. Оно управляется несколькими панелями с разными настройками. Я должен MainModel создавать и передавать DomainObject эти ChartView выходные данные. Поскольку существует несколько панелей, и я не хотел делать MainModel их огромными, он создает ChildModels для каждой панели свои собственные представления. В свою очередь, MainController присоединяется ChildControllers к ним. ‘ChartView’ регистрирует себя для наблюдения за изменениями, MainModel чтобы обновить выходные данные.

Первая проблема заключается в том, что, поскольку ChildModels они в основном являются частями MainModel , их изменения должны вызывать обновления ChartView (помимо их собственных представлений). Чтобы решить эту проблему, мне пришлось MainModel вручную зарегистрировать его дочерние ChartView элементы. Итак, теперь у меня есть несколько подключенных моделей ChartView . Хотя я знаю, что это, вероятно, вызвано плохим дизайном (модель, которая создает дочерние модели и так далее), решение сработало нормально. Но я хотел бы услышать другие подходы к разделению одной большой модели. У меня была одна идея MainModel — прослушивать изменения ChildModels и уведомлять ChartView . Таким образом, взаимодействует только с одной моделью ChartView .

Вторая проблема — запуск ChartView обновлений по цепочке. Это происходит потому, что все эти панели с настройками имеют некоторые значения, которые зависят друг от друга. Итак, если пользователь вводит некоторое значение first panel , диапазон, из которого значение second panel может измениться. Когда контроллер обновляет second panel его, он срабатывает StateChange Event . И поскольку ChartView он был включен для прослушивания обновлений ChildModels , он получит уведомление об обновлении с обеих панелей. Теперь, в моем случае, у меня их 8. Это делает один единственный ввод от пользователя, приводящий к 8 ChartView перерисовкам. Что, вероятно, опять же является результатом плохого дизайна. Но в этом случае я понятия не имею, как правильно обрабатывать эти множественные уведомления об обновлении и GraphView обновлять только по последнему запросу. Мое решение состояло в том, чтобы делать транзакционные обновления. Вместо одного уведомления для просмотра модели отправляют beginUpdate и endUpdate уведомления. Только после получения представления endUpdate оно запрашивает модель для обновленных данных. Таким образом, уведомления об обновлении вложенной модели как бы «отключаются».

Я хотел бы знать, как вы подходите к этим проблемам. Спасибо

Ответ №1:

Насколько я понимаю вашу озабоченность, ошибка заключается в ChartView одновременном прослушивании нескольких моделей. MVC предполагает, что существует только одна модель. Поэтому ChartView следует подключаться только к MainModel . Цель MainModel состоит в том, чтобы правильно мультиплексировать изменения, поступающие с панелей, и отправлять события ChartView . Ваша идея MainModel прослушивания дочерних моделей и обслуживания ChartView выглядит для меня как правильный дизайн.

Что касается вашего второго вопроса, обычное использование заключается в логическом параметре (например multiple ) в событии. Значение true указывает, что следующее событие является частью последовательности, и false означает, что последовательность завершена. Если событие не является частью последовательности, установите для параметра значение false (что означает последовательность длиной 1). В вашем случае просто игнорируйте события с true помощью и ждите, пока false события запросят стабильное состояние.

Комментарии:

1. Вы упоминаете, что «MVC предполагает, что существует только одна модель». JTable Например, A может иметь модель данных, модель столбцов, модель выбора и т. Д. Можете ли вы подробнее остановиться на этом?

2. Здесь, когда вы говорите о моделях данных / столбцов / выбора, вы на самом деле говорите о 3 разных экземплярах MVC, даже если они вносят вклад в один и тот же компонент swing.

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