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

Question

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

У меня есть два случая в виду:

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

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

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

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

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

Edit 1:

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

Answer 1

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

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

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

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

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

Answer 2

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

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

Возможно, вам стоит взглянуть на MVC page на wikipedia для обзора.

Answer 3

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