Отношения между элементами MVC

Question

Может кто-нибудь объяснить отношения между элементами MVC (с активной моделью), нарисованными на этой картинке?

Я вижу это так:

1. Контроллер → Модель - данные модели изменяются контроллером.
2. Модель → Вид - модель уведомляет вид об изменении.
3. Вид → Модель - представление получает данные из модели.
4. Вид → Контроллер - представление уведомляет контроллер о действиях пользователя (например, нажатие кнопки).
5. Контроллер → Представление - но это отношение, как мне кажется, не нужно и противоречит правилу MVC о разработке контроллера независимо от представления: он должен взаимодействовать через модель.

Answer 1

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

Еще одна вещь - существование контроллеров, независимых от точки зрения, на мой взгляд, миф в реальных сценариях. Рано или поздно вам нужно предоставить функциональность, которая явно ужесточает отношение View-Controller и становится непригодной (или просто другой) без этого конкретного View. Кроме того, гораздо эффективнее принять тот факт, что различные типы представлений ведут себя по-разному, и превратить это в преимущество, создав специализированные контроллеры, вместо того, чтобы притворяться, что мы можем иметь дело с каждым аспектом взаимодействия с пользователем только с одним.

Answer 2

Что касается отношения controller-> view , которое вы выделили

• Контроллер должен иметь возможность выбирать соответствующий отображаемый вид

AFAIK, это единственное отношение, которое контроллер имеет к представлению (за исключением сообщений маршрутизации представления к контроллеру). MVC немного отличается от MVVM / MVP, потому что вам не обязательно иметь только одно представление для каждого контроллера. Например, у вас может быть пользовательский контроллер, и у вас может быть представление для отображения информации, одно для редактирования пользователей и одно для добавления пользователей. В двух других методах между представлениями и ViewModels или Presenters существует взаимно-однозначное отношение.

• Контроллеры, независимые от представления, не миф

Возможно, я недостаточно использовал MVC в других сценариях, но я всегда держал контроллер независимо от вида. Фактически, если у вас есть какой-либо код представления в вашем контроллере (т.е. функция с ListBoxEventArgs, ссылающаяся на компоненты представления и т. Д.), То вы не достигли цели этого шаблона, которая заключается в том, чтобы отделить ваше представление от вашей логики и модели. Я считаю, что ASP.NET MVC делает представления полностью независимыми от контроллера благодаря наличию некоторого класса, который управляет отслеживанием инициированных представлений. Этот класс доступен для всех контроллеров (через наследование, но внедрение зависимостей тоже хорошо), а затем каждый контроллер просто выбирает представление для отображения с использованием этого класса. Представление может быть выбрано с помощью константы или строки (на самом деле, я полагаю, что можно даже выбрать их без аргумента и на основе имени метода).

---

просмотр-> отношение контроллера

В ASP.NET MVC представления также не зависят от контроллера, так как события направляются в контроллер через URL. Тем не мение. в других ситуациях, не связанных с Интернетом, можно просто переслать ваши события в контроллер, напрямую вызывая методы контроллера в коде.

---

Детали реализации

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

MVVM против MVP против MVC: объясненные различия

Лично я думаю, что тип MVC, показанный на вашей диаграмме, используется не так часто, как в прошлом, и может быть трудно найти примеры, которые используют эти отношения, как показано. Причина в том, что если представление может взаимодействовать с моделью, то, я думаю, разработчики выберут MVP или MVVM (и используют модель представления) вместо MVC. Единственный случай, когда я могу вспомнить, когда представление не может постоянно общаться с моделью, - это ситуации с клиентским сервером. В этом случае существует множество популярных MVC-фреймворков, таких как ASP.NET MVC до сих пор популярны.

Answer 3

Я думаю, что соотношение между моделью и представлением неправильное (по крайней мере, твердое).То, как я это вижу в паттерне MVC, заключается в том, что все проходит через контроллер.Таким образом, в представлении пользователь выбирает данные, которые он хочет видеть. Этот запрос отправляется контроллеру.Контроллер собирается получить данные в модели, а модель возвращает запрошенные данные.Затем контроллер отправляет его обратно в представление, а представление выводит его пользователю.