Блог

У меня есть модель со ссылкой на представление, контроллер со ссылками на модель и представление и несвязанное представление без ссылок на вышеупомянутое.

Контроллер имеет всех слушателей представления и обрабатывает события, вызывая методы в модели и представлении. Модель вызывает методы представления в некоторых из своих методов.

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

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

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

Подводя итог, контроллер вносит изменения в модель, которая уведомляет заинтересованные стороны (включая представление). Представление содержит ссылку на модель для извлечения данных.

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

Модель не должна ничего знать о представлении. Представление должно знать, как заполнять себя с учетом модели.

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

Существует так много вариантов MVC, что я откажусь называть любой из них «неправильным».

Смотрите http://martinfowler.com/eaaDev/uiArchs.html

Найдите подходящий вариант и используйте его.

На рабочем столе Swing есть хорошая библиотека GUI. Ознакомьтесь с этой статьей, чтобы увидеть, как она соотносится с MVC. Для предприятий взгляните на шаблон контроллера представления модели Мартина Фаулера (330) для веб-приложений. Если у вас нет его книги (Шаблоны архитектуры корпоративных приложений), я настоятельно рекомендую раздобыть копию.

В блоге есть хорошая статья по Sun.com : Разработка приложений Java SE с использованием MVC. Он начинается с объяснения «классического» шаблона MVC, где представление и модель напрямую взаимодействуют друг с другом, а затем переходит к более новому шаблону MVC «централизованный контроллер», где представление и модель могут взаимодействовать друг с другом только через контроллер (модель отделена от представления). Он также содержит пример, ориентированный на Swing.