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