Используя MVC, как следует обрабатывать связь между представлениями? Между моделями?

Question

Вопрос номер три в моем стремлении правильно понять MVC до Я его реализую:

Я имею в виду два случая:

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

Эти вопросы связаны с тем, что они оба связаны с обменом данными через триплеты Model-View-Controller - тема, о которой я не нашел большого обсуждения в своем поиске по Google.

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

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

В более широком смысле, если у кого-нибудь есть ссылка, показывающая типичные подходы к такого рода проблемам MVC, я бы хотел ее увидеть. Мне не очень повезло найти твердые, нетривиальные ссылки. Примеры на Python были бы хороши, но я с удовольствием прочитаю что угодно.

Редактировать 1 :

Я вижу некоторые довольно интересные вещи, сказанные ниже, и в целом, похоже, ни у кого нет проблем с подходом, который я описал. Это уже почти ленивая форма дизайна FrontController, которую описывает Винсент. Я, конечно, не предвижу никаких проблем в реализации этого паттерна, однако не похоже, чтобы кто-то действительно обращался к этому вопросу в отношении коммуникации между моделями. Все ответы, кажется, касаются связи между объектами в одной модели. Меня больше интересует поддержка отдельных моделей для отдельных компонентов приложения, чтобы я не вставлял пятьдесят свойств состояния в один класс Model. Должен ли я поддерживать их как подмодели вместо этого?

Answer 1

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

Что касается (3), компоненты модели, безусловно, могут быть связаны друг с другом. Это не является неожиданным и не следует избегать, обязательно. Например, ваша модель клиента может иметь связанный набор заказов. Было бы совершенно естественно получить доступ к заказам клиента с помощью метода в классе Customer.

Возможно, вы захотите взглянуть на страницу MVC в Википедии для обзора.

Answer 2

Вы можете рассмотреть вопрос о поиске шаблона проектирования Front Controller.

Шаблон Front Controller определяет один компонент, который отвечает за обработку запросов приложений. Фронт-контроллер централизует такие функции, как выбор вида, безопасность и шаблоны, и последовательно применяет их ко всем страницам или представлениям. Следовательно, когда необходимо изменить поведение этих функций, необходимо изменить только небольшую часть приложения: контроллер и его вспомогательные классы.

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

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

Эта статья может помочь. И это один.

Answer 3

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