Я прочитал много статей об архитектуре MVC, но я все еще смущен.
Схема 1
Схема 2
Схема 3
MVC можно понять, подумав об ответственности:
Представлению не разрешено изменять состояние модели напрямую - только через Контроллер. Представление все еще может иметь прямой доступ к модели, хотя только для просмотра (или имея копию, не являющуюся официальной моделью).
Модель должна жить в своем собственном юниверсе и не иметь никаких ссылок на контроллеры или представления.
Контроллер контролирует состояние и доступ к модели.
Определенно не диаграмма 3! Диаграмма 1 в порядке. Я думаю, что лучше всего в основном диаграмма 2 со стрелкой от контроллера к просмотру.
Предполагая, что вы спрашиваете в контексте веб-приложений, я думаю, вот как выглядит хороший поток MVC:
Когда приходит веб-запрос, это один из двух типов.
Тип A - это простой запрос, который напрямую сопоставляется с представлением, поэтому контроллер не задействован
Тип B - это запрос, который сопоставляется с контроллером
Для обоих типов A и B представление всегда считывает данные из моделей напрямую
. Если это запрос типа B, контроллер считывает / обновляет модели и по завершении просит платформу MVC вернуть представление клиенту. Представление считывает модели обновлений и отображает их клиенту.
Этот подход поддерживается платформой Induction MVC .
Надеюсь, это поможет.
Моя стратегия изучения хороших методов MVC заключалась в том, чтобы найти кого-то, кто знает, и задать много вопросов. Обращение к кучке людей, которые не знают ваших требований, намерений или идей, не принесет много пользы.
Я считаю, что диаграмма 1 будет считаться «лучшей» диаграммой, но, не зная вашей уникальной ситуации, было бы лучше объяснить ваши потребности тому, кто знает ваши требования и архитектуру MVC.