Я знаю, что это старый (старый) вопрос, но я указывал на него как на пример использования "View Model" в контексте MVC. Я утверждаю, что это неправильно и может привести к путанице со стороны людей, которые плохо знакомы с / или / обеими моделями. Кто бы ни делал это - stahp. Вот почему (и это даже окольный ответ на первоначальный вопрос).
Пример того, когда это происходит, можно увидеть в этом вопросе . Пользователь пытается использовать модель представления, которая реализует INotifyPropertyChanged в приложении ASP.NET MVC, таким образом объединяя дизайн рабочего стола и веб-приложения без сохранения состояния в архитектурном сбое и горе.
Проще говоря, в шаблоне MVC нет "View Model". Там есть , однако, это функциональный эквивалент, и это Контроллер. Просто чтобы прояснить детали и их смысл,
MVVM (настольные приложения):
- Модель - Объект со строгой типизацией, содержащий данные, передаваемые между представлением и моделью представления
- Просмотр - Пользовательский интерфейс, просматриваемый пользователем и через который пользователь взаимодействует с системой
- Просмотр модели - Интерпретирует действия пользователя (например, через ICommand), выполняет их, обновляет состояние приложения
MVC (веб-приложения):
- Модель - строго типизированный * объект, который содержит данные, передаваемые между представлением и представлением модели
- Просмотр - Генератор пользовательского интерфейса, который комбинирует модель, код и HTML для отображения веб-страницы
- Контроллер - Принимает запросы пользователей, интерпретирует их, обновляет состояние приложения и использует представление для преобразования этого состояния в веб-страницу HTML
Модель практически одинакова в обеих моделях. Модели настольных компьютеров могут реализовывать уведомления о событиях обновления, веб-модели могут быть динамическими (то есть не строго типизированными), и обе могут включать или не включать методы проверки или метаданные.
Вид на рабочем столе - это то, что видит пользователь. В Интернете это генератор, который выводит HTML для браузеров для отображения на стороне клиента. Он должен интерпретировать взаимодействие пользователя на рабочем столе, но в Интернете, который обрабатывается клиентским JavaScript, браузером и запросами, которые отправляются обратно на сервер.
Модель представления / Контроллер примерно функционально эквивалентны, но сильно различаются в том, как они реализованы и как они работают. В View Model взаимодействие пользователя с приложением передается в View Models с помощью ICommands, маршрутизируемых событий и других методов (многие инфраструктуры MVVM предоставляют различные способы привязки View Models к пользовательскому интерфейсу и другим частям приложения). ). В контроллере поступает запрос со всей информацией, необходимой для контроллера, чтобы возвратить результат пользователю (при условии, что это запрос 200 OK). Контроллер должен выполнить любую работу, необходимую для создания состояния (иначе называемого Model), необходимого генератору HTML (представлению) для создания ответа. С точки зрения дизайна, Контроллер находится над View и Model, зная и управляя обоими, тогда как ViewModel находится рядом с View, передавая Модель (и другую информацию) между ними.
Что действительно смущает некоторых людей, так это то, что клиентские инфраструктуры MVVM , которые вы можете смешать с вашим MVC-приложением. Они существуют исключительно в javascript в браузере пользователя и не имеют никакого отношения к какому-либо конкретному шаблону, которому вы придерживаетесь на стороне сервера. Вы можете запустить классический ASP-сайт, который использует MVVM на стороне клиента. Черт, вы можете запускать статические HTML-страницы, которые используют MVVM на стороне клиента. Они такие разные.
Эти структуры MVVM javascript, как правило, следуют шаблону, аналогичному описанному выше шаблону MVVM для настольных компьютеров, но настроены для более точной работы с природой HTML DOM и javascript. Например, в DOM нет обширной системы привязки, а javascript имеет очень ограниченную систему типов, поэтому сопоставление шаблонов с моделями значительно отличается от сопоставления в WPF. Они также обычно работают независимо от сервера и, когда им нужно взаимодействовать, предпочитают вызовы AJAX, а не отправку страницы обратно в контроллер (вызовы AJAX обычно обрабатываются контроллерами WebAPI в ASP.NET MVC).
Итак, подведем итог: в MVC действительно нет модели представления. Контроллер является грубым эквивалентом, но он сильно отличается в том, как он получает пользовательский ввод, интерпретирует его и возвращает результат пользователю. Использование термина «Модель представления» для ссылки на что-либо в MVC может привести только к путанице, и поэтому его следует избегать. Используйте правильные термины для правильных частей шаблона. Это может показаться педантичным, но это должно помочь сохранить ясность и быть менее запутанным для людей, которые плохо знакомы с обоими образцами.