#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 заключается в подключении представления к модели, а не в мультиплексировании ввода из разных источников. Такая функциональность должна быть реализована на уровне модели, чтобы исключить представление из этой произвольной сложности.