Мне нравится думать об этом так:
Виды, как вы говорите, тупые.Джош Смит, автор оригинальной и часто связанной статьи MSDN о MVVM, сказал, что представления - это «одежда, которую носят данные».Представления никогда не содержат данных и не управляют ими напрямую, они просто привязаны к свойствам и командам ваших моделей представления.
Модели - это объекты, которые моделируют домен вашего приложения , как в бизнес-объектах.Является ли ваше приложение музыкальным магазином?Возможно, вашими модельными объектами станут художники, альбомы и песни.Является ли ваше приложение браузером орг-чарта?Возможно, вашими модельными объектами станут менеджеры и сотрудники.Эти объекты модели не связаны с каким-либо визуальным рендерингом, и они даже не имеют прямого отношения к приложению, в которое вы их помещаете - ваши объекты модели должны иметь смысл сами по себе как семейство объектов, которые представляют некоторый виддомена.Уровень модели также обычно включает в себя такие вещи, как средства доступа к службам.
Это приводит нас к Viewmodels.Кто они такие?Это объекты, которые моделируют приложение с графическим интерфейсом , что означает, что они предоставляют данные и функциональные возможности для использования представлениями.Именно они определяют структуру и поведение реального приложения, которое вы создаете.Для объектов модели домен - это любой домен, который вы выберете (музыкальный магазин, браузер орг-диаграммы и т. Д.), Но для модели представления домен является графическим приложением.Ваши модели представления будут инкапсулировать поведение и данные всего, что делает ваше приложение.Они собираются выставлять объекты и списки как свойства, а также такие вещи, как команды.Команда - это просто поведение (в простейшем случае - вызов метода), заключенное в объект, который его переносит - эта идея важна, потому что представления управляются привязкой данных, которая присоединяет визуальные элементы управления к объектам.В MVVM вы не назначаете кнопке метод обработчика Click, вы связываете ее с объектом команды (обслуживаемым из свойства в модели представления), который содержит функциональные возможности, которые вы хотите запускать при нажатии на нее.
Для меня наиболее запутанными были следующие биты:
- Несмотря на то, что модели представления являются моделями графического приложения, они не ссылаются напрямую или не используют визуальные концепции.Например, вам не нужны ссылки на элементы управления Windows в ваших ViewModels - эти вещи идут в представлении.ViewModels просто предоставляют данные и поведение элементам управления или другим объектам, которые будут с ними связываться.Например - у вас есть представление с ListBox в нем?У вашей модели представления почти наверняка будет какая-то коллекция.Есть ли у вашего вида кнопки?У вашей модели представления почти наверняка будут какие-то команды.
- Существует несколько видов объектов, которые можно считать "моделями представления". Простейший вид модели представления для понимания - это модель, которая непосредственно представляет элемент управления или экран в соотношении 1: 1, как на экране «XYZ» имеет текстовое поле, список и три кнопки, поэтому для модели представления требуется строка, коллекция, и три команды ". Другой тип объекта, который вписывается в слой модели представления, - это обертка вокруг объекта модели, которая придает ему поведение и делает его более удобным для представления - вот где вы попадаете в понятия «толстый» и «тонкий» слои модели представления. «Тонкий» слой модели представления представляет собой набор моделей представления, которые предоставляют ваши объекты модели непосредственно представлениям, что означает, что представления в конечном итоге привязываются непосредственно к свойствам объектов модели. Это может работать для таких вещей, как простые представления только для чтения, но что, если вы хотите, чтобы поведение было связано с каждым объектом? Вы не хотите этого в модели, потому что модель не связана с приложением, она связана только с вашим доменом. Вы можете поместить его в объект, который оборачивает объект вашей модели и предлагает более удобные для привязки данные и поведение. Этот объект-обертка также считается моделью представления, и его получение приводит к созданию «более толстого» слоя модели представления, в котором ваши представления никогда не заканчиваются прямой привязкой к чему-либо в классе модели. Коллекции будут содержать модели представления, которые обертывают модели, а не только сами модели.
Кроличья нора еще глубже - есть множество идиом, таких как ValueConverters, которые поддерживают MVVM, и есть много чего применить, когда вы начинаете думать о таких вещах, как смешиваемость, тестирование и способ передачи данных в вашем приложении и убедитесь, что у каждой модели представления есть доступ к поведению, в котором она нуждается (именно здесь происходит внедрение зависимости), но, надеюсь, вышесказанное - хорошее начало. Главное - думать о ваших визуальных элементах, вашем домене, структуре и поведении вашего реального приложения как о трех разных вещах.