Основные понятия MVVM: что должен делать ViewModel?

Ответ 1

Мне нравится думать об этом так:

Представления, как вы говорите, глупы. Джош Смит, писатель семенной и часто связанной статьи MSDN о MVVM, сказал, что представления - это "одежда, которая носит данные". Представления никогда не содержат данных или непосредственно манипулируют им, они просто привязаны к свойствам и командам ваших моделей просмотра.

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

Это приводит нас к Viewmodels. Кто они такие? Это объекты, которые моделируют приложение GUI, а это означает, что они предоставляют данные и функции, которые будут использоваться представлениями. Это то, что определяет структуру и поведение фактического приложения, которое вы строите. Для объектов модели домен - это любой домен, который вы выберете (музыкальный магазин, браузер организационной диаграммы и т.д.), Но для модели просмотра этот домен является графическим приложением. Ваши модели представлений будут инкапсулировать поведение и данные всего, что делает ваше приложение. Они собираются выставлять объекты и списки как свойства, а также такие вещи, как Commands. Команда - это просто поведение (в самом простом, вызов метода), завернутое в объект, который его переносит - эта идея важна, потому что представления управляются привязкой данных, которая прикрепляет визуальные элементы управления к объектам. В MVVM вы не даете кнопке метод Click handler, вы привязываете его к объекту команды (обслуживаемому из свойства в режиме просмотра), который содержит функции, которые вы хотите запустить при нажатии на нее.

Для меня наиболее запутанные биты были следующими:

• Несмотря на то, что модели просмотра являются моделями графического приложения, они напрямую не ссылаются или не используют визуальные концепции. Например, вам не нужны ссылки на элементы управления Windows в ваших моделях ViewModels - все это происходит в представлении. ViewModels просто выставляют данные и поведение элементам управления или другим объектам, которые будут привязываться к ним. Например - у вас есть представление со списком в нем? В вашей модели просмотра почти наверняка будет какая-то коллекция. У вашего вида есть кнопки? Ваша модель просмотра почти наверняка будет иметь в ней несколько команд.
• Есть несколько видов объектов, которые можно было бы рассматривать как "viewmodels". Простейший вид viewmodel для понимания - это тот, который непосредственно представляет собой элемент управления или экран в соотношении 1:1, так как в "экране XYZ есть текстовое поле, список и три кнопки, поэтому для модели просмотра требуется строка, и три команды". Другой вид объекта, который вписывается в слой viewmodel, представляет собой оболочку вокруг объекта модели, которая дает ему поведение и делает его более удобным для использования по представлению - здесь вы попадаете в понятия "толстые" и "тонкие" слои viewmodel. "Тонкий" слой viewmodel представляет собой набор режимов просмотра, которые отображают ваши объекты модели непосредственно в представлениях, что означает, что представления в конечном итоге привязываются непосредственно к свойствам объектов модели. Это может работать для таких вещей, как простые представления только для чтения, но что, если вы хотите иметь поведение, связанное с каждым объектом? Вы не хотите, чтобы в модели, потому что модель не связана с приложением, она относится только к вашему домену. Вы можете поместить его в объект, который обертывает ваш объект модели и предлагает более дружественные к делу данные и поведение. Этот объект-оболочка также рассматривается как viewmodel, и с их результатом получается "более толстый" слой viewmodel, где ваши представления никогда не будут напрямую привязываться к чему-либо в классе модели. Коллекции будут содержать модели просмотра, которые обертывают модели, а не просто содержат сами модели.

У кроличьей дыры глубже - есть много идиом, чтобы понять, как ValueConverters, которые поддерживают MVVM, и там многого можно применить, когда вы начинаете думать о вещах, таких как Blendability, testing и о том, как передавать данные в вашем приложении и убедитесь, что каждая модель просмотра имеет доступ к поведению, в котором она нуждается (именно там происходит инъекция зависимостей), но, надеюсь, это хорошее начало. Ключ должен думать о ваших изображениях, вашем домене, структуре и поведении вашего фактического приложения как о трех разных вещах.

Ответ 2

Используя эту невероятно полезную статью в качестве источника, вот резюме для Просмотр, ViewModel и Model.

Вид:

• Вид - это визуальный элемент, например окно, страница, пользовательский элемент управления или шаблон данных. Представление определяет элементы управления, содержащиеся в представлении, и их визуальную компоновку и стиль.

• Вид ссылается на модель представления с помощью свойства DataContext. Элементы управления в представлении привязаны к свойствам и командам, отображаемым моделью просмотра.

• Представление может настраивать поведение привязки данных между представлением и моделью представления. Например, в представлении могут использоваться преобразователи значений для форматирования данных, которые будут отображаться в пользовательском интерфейсе, или он может использовать правила проверки для предоставления пользователю дополнительной проверки входных данных.

• Представление определяет и обрабатывает визуальное поведение пользовательского интерфейса, такое как анимация или переходы, которые могут быть вызваны из изменения состояния в модели представления или посредством взаимодействия пользователя с пользовательским интерфейсом.

• Кодирование кода представления может определять логику пользовательского интерфейса для реализации визуального поведения, которое трудно выразить в XAML или для которого требуются прямые ссылки на определенные элементы пользовательского интерфейса, определенные в представлении.

Примечание:
Поскольку модель представления не должна иметь явного знания конкретных визуальных элементов в представлении, код для программного манипулирования визуальными элементами в представлении должен находиться в образе кода или быть инкапсулирован в поведении.

Модель просмотра:

• Модель просмотра - это невизуальный класс и не является базовым классом WPF или Silverlight. Он инкапсулирует логику представления, необходимую для поддержки прецедента или пользовательской задачи в приложении. Модель просмотра может быть проверена независимо от вида и модели.

• Обычно модель просмотра напрямую не ссылается на представление. Он реализует свойства и команды, к которым может привязываться представление. Он уведомляет мнение о любых изменениях состояния посредством событий уведомления об изменениях через INotifyPropertyChanged и INotifyCollectionChanged интерфейсы.

• Модель просмотра координирует взаимодействие вида с моделью. Он может преобразовывать или манипулировать данными, чтобы он мог легко потреблять вид и мог реализовывать дополнительные свойства, которые могут отсутствовать в модели. Он также может осуществлять проверку данных через интерфейсы IDataErrorInfo или INotifyDataErrorInfo.

• Модель представления может определять логические состояния, которые вид может представлять визуально для пользователя.

Примечание:
Все, что важно для логического поведения приложения, должно войти в модель представления. Код для извлечения или управления элементами данных, которые должны отображаться в представлении посредством привязки данных, должен находиться в модели представления.

Модель:

• Классы моделей - это не визуальные классы, которые инкапсулируют данные приложения и бизнес-логику. Они отвечают за управление данными приложения и за обеспечение его согласованности и достоверности путем инкапсуляции необходимых бизнес-правил и логики проверки данных.

• Классы моделей напрямую не ссылаются на классы представления или представления модели и не зависят от того, как они реализованы.

• Классы моделей обычно предоставляют события уведомления об изменениях свойств и коллекции через интерфейсы INotifyPropertyChanged и INotifyCollectionChanged. Это позволяет им легко привязывать данные в представлении. Классы моделей, представляющие коллекции объектов, обычно выводятся из класса ObservableCollection<T>.

• Классы моделей обычно обеспечивают проверку данных и сообщение об ошибках через интерфейсы IDataErrorInfo или INotifyDataErrorInfo.

• Классы моделей обычно используются совместно с сервисом или репозиторием, который инкапсулирует доступ к данным и кеширование.

Ответ 3

Я написал это как "простой английский", как я могу представить в эту серию на MVVM. В частности, эта диаграмма, вероятно, является самым простым, коротким объяснением.

Говоря в основном, "модель" - это ваши данные или бизнес-правила. Он действительно не должен знать о том, как и где он будет использоваться, и особенно не о том, какая технология собирается его использовать. "Модель" - это основная суть приложения - и не нужно беспокоиться о том, является ли приложение WPF, Silverlight, Windows Forms, ASP.NET и т.д. - он просто "сам" в чистой форме.

"Вид" - это часть, которая полностью зависит от технологии. В MVVM, в идеале, представление должно быть почти 100% XAML, так как это дает некоторые огромные выгоды для гибкости.

Тем не менее, должно быть что-то, что переводит информацию из Модели в ту или иную форму, где она может быть использована технологией под рукой - здесь и появляется ViewModel. Например, это часто "завершает" классы модели в "ViewModel" для этих конкретных данных, которые включают в себя Команды (для запуска логики), реализует INotifyPropertyChanged (для поддержки привязки данных) и т.д. Что это - это мост, который делает модель пригодной для использования в представлении.

Ответ 4

Отличное введение в MVVM можно найти в видео Jason Dolinger здесь. Я продолжал видео со мной довольно долго, когда я начинал, это действительно полезно.

Ответ 5

Построение ViewModel, представляющего согласованный фасад над базовой моделью, может быть намного сложнее, чем выглядит. Эта статья о создании объектов ViewModel демонстрирует, как создать ViewModel, и иллюстрирует некоторые из проблем, с которыми вы столкнетесь - вместе с тем, которые выглядят как разумные решения, Когда я его читал, раздел о работе с коллекциями отсутствовал, но у него все еще были интересные моменты.