Основные понятия MVVM- что должен делать ViewModel?
Пытаясь понять концепции MVVM, я уже прочитал несколько блогов и посмотрел несколько проектов.
Из того, что я понимаю, представление тупо, оно просто знает, как представить то, что ему передают.
Модели - это просто простые данные, а ViewModel - это то, что действует как дополнение между ними, что оно должно получать информацию из модели и передавать ее в представление, а представление должно знать, как ее представить. Или наоборот, если информация в представлении изменяется, она должна передать изменение в модель.
Но я до сих пор не знаю, как применить концепцию. Может кто-нибудь объяснить очень простой сценарий, чтобы я мог понять концепцию? Я уже посмотрел несколько проектов, но они все еще не имеют полного смысла, поэтому, если бы кто-то мог написать их на простом английском языке, это было бы хорошо.
5 ответов
Мне нравится думать об этом так:
Взгляды, как вы говорите, тупые. Джош Смит, автор оригинальной и часто связанной статьи MSDN о MVVM, сказал, что представления - это "одежда, которую носят данные". Представления никогда не содержат данных и не манипулируют ими напрямую, они просто связаны со свойствами и командами ваших моделей представления.
Модели - это объекты, которые моделируют домен вашего приложения, как в бизнес-объектах. Является ли ваше приложение музыкальным магазином? Возможно, вашими модельными объектами станут художники, альбомы и песни. Является ли ваше приложение браузером орг-чарта? Возможно, вашими модельными объектами станут менеджеры и сотрудники. Эти объекты модели не связаны с каким-либо визуальным рендерингом, и они даже не имеют прямого отношения к приложению, в которое вы их помещаете - ваши объекты модели должны иметь смысл сами по себе как семейство объектов, которые представляют некоторый вид домена. Уровень модели также обычно включает в себя такие вещи, как средства доступа к службам.
Это подводит нас к Viewmodels. Кто они такие? Это объекты, которые моделируют приложение с графическим интерфейсом, то есть они предоставляют данные и функциональные возможности для использования представлениями. Именно они определяют структуру и поведение реального приложения, которое вы создаете. Для объектов модели домен - это любой домен, который вы выберете (музыкальный магазин, браузер орг-диаграммы и т. Д.), Но для модели представления домен является графическим приложением. Ваши модели представления будут инкапсулировать поведение и данные всего, что делает ваше приложение. Они собираются выставлять объекты и списки как свойства, а также такие вещи, как команды. Команда - это просто поведение (в простейшем случае - вызов метода), заключенное в объект, который его переносит - эта идея важна, потому что представления управляются привязкой данных, которая присоединяет визуальные элементы управления к объектам. В MVVM вы не назначаете кнопке метод обработчика Click, вы связываете ее с объектом команды (обслуживаемым из свойства в модели представления), который содержит функциональные возможности, которые вы хотите запускать при нажатии на нее.
Для меня самые запутанные моменты были следующие:
- Несмотря на то, что модели представления являются моделями графического приложения, они не ссылаются напрямую или не используют визуальные концепции. Например, вам не нужны ссылки на элементы управления Windows в ваших ViewModels - эти вещи идут в представлении. ViewModels просто предоставляют данные и поведения элементам управления или другим объектам, которые будут с ними связываться. Например - у вас есть представление с ListBox в нем? У вашей модели представления почти наверняка будет какая-то коллекция. У вашего взгляда есть кнопки? У вашей модели представления почти наверняка будут какие-то команды.
- Есть несколько видов объектов, которые можно считать "моделями представления". Простейший вид модели представления для понимания - это модель, которая непосредственно представляет элемент управления или экран в соотношении 1:1, как на экране "XYZ" имеет текстовое поле, список и три кнопки, поэтому для модели представления требуется строка, коллекция, и три команды ". Другой тип объекта, который вписывается в слой модели представления, - это обертка вокруг объекта модели, которая придает ему поведение и делает его более удобным для представления - вот где вы попадаете в понятия "толстый" и "тонкий" слои модели представления."Тонкий" слой модели представления представляет собой набор моделей представления, которые предоставляют ваши объекты модели непосредственно представлениям, что означает, что представления в конечном итоге привязываются непосредственно к свойствам объектов модели. Это может работать для таких вещей, как простые представления только для чтения, но что, если вы хотите, чтобы поведение было связано с каждым объектом? Вы не хотите этого в модели, потому что модель не связана с приложением, она связана только с вашим доменом. Вы можете поместить его в объект, который оборачивает объект вашей модели и предлагает более удобные для привязки данные и поведение. Этот объект-обертка также считается моделью представления, и его получение приводит к созданию "более толстого" слоя модели представления, где ваши представления никогда не заканчиваются прямой привязкой к чему-либо в классе модели. Коллекции будут содержать модели представления, которые обертывают модели, а не только сами модели.
Кроличья нора еще глубже - есть много идиом, таких как ValueConverters, которые поддерживают MVVM, и есть что применить, когда вы начинаете думать о таких вещах, как смешиваемость, тестирование и как передавать данные в вашем приложении и гарантировать, что каждая модель представления имеет доступ к нужному поведению (именно здесь происходит внедрение зависимости), но, надеюсь, вышесказанное - хорошее начало. Главное - думать о ваших визуальных элементах, вашем домене, структуре и поведении вашего реального приложения как о трех разных вещах.
Используя эту невероятно полезную статью в качестве источника, приведу сводку по View, ViewModel и Model.
Посмотреть:
Представление представляет собой визуальный элемент, такой как окно, страница, пользовательский элемент управления или шаблон данных. Представление определяет элементы управления, содержащиеся в представлении, а также их визуальное расположение и стиль.
Представление ссылается на модель представления через ее
DataContextимущество. Элементы управления в представлении - это данные, связанные со свойствами и командами, предоставляемыми моделью представления.Представление может настраивать поведение привязки данных между представлением и моделью представления. Например, представление может использовать преобразователи значений для форматирования данных, которые должны отображаться в пользовательском интерфейсе, или оно может использовать правила проверки для обеспечения дополнительной проверки входных данных для пользователя.
Представление определяет и обрабатывает визуальное поведение пользовательского интерфейса, такое как анимация или переходы, которые могут быть вызваны изменением состояния в модели представления или взаимодействием пользователя с пользовательским интерфейсом.
Кодовая часть представления может определять логику пользовательского интерфейса для реализации визуального поведения, которое трудно выразить в XAML или которое требует прямых ссылок на конкретные элементы управления пользовательского интерфейса, определенные в представлении.
НОТА:
Поскольку модель представления не должна иметь явных знаний о конкретных визуальных элементах в представлении, код для программного манипулирования визуальными элементами в представлении должен находиться в выделенном коде представления или быть инкапсулированным в поведении.
Посмотреть модель:
Модель представления является невизуальным классом и не является производной от какого-либо базового класса WPF или Silverlight. Он инкапсулирует логику представления, необходимую для поддержки варианта использования или пользовательской задачи в приложении. Модель вида тестируется независимо от вида и модели.
Модель представления обычно не ссылается непосредственно на представление. Он реализует свойства и команды, с которыми представление может связывать данные. Он уведомляет о любых изменениях состояния через события уведомления об изменениях через
INotifyPropertyChangedа такжеINotifyCollectionChangedинтерфейсы.Модель представления координирует взаимодействие представления с моделью. Он может преобразовывать или манипулировать данными, чтобы их можно было легко использовать в представлении, и реализовывать дополнительные свойства, которые могут отсутствовать в модели. Он также может осуществлять проверку данных через
IDataErrorInfoили жеINotifyDataErrorInfoинтерфейсы.Модель представления может определять логические состояния, которые представление может представлять визуально для пользователя.
НОТА:
Все, что важно для логического поведения приложения, должно входить в модель представления. Код для извлечения или обработки элементов данных, которые должны отображаться в представлении посредством привязки данных, должен находиться в модели представления.
Модель:
Классы моделей - это невизуальные классы, которые инкапсулируют данные приложения и бизнес-логику. Они несут ответственность за управление данными приложения и за обеспечение его согласованности и достоверности путем инкапсуляции необходимых бизнес-правил и логики проверки данных.
Классы модели не ссылаются напрямую на классы представления или модели представления и не зависят от того, как они реализованы.
Классы модели обычно предоставляют события уведомления об изменениях свойств и коллекций через
INotifyPropertyChangedа такжеINotifyCollectionChangedинтерфейсы. Это позволяет им быть легко привязанными к данным в представлении. Модельные классы, которые представляют коллекции объектов, обычно происходят отObservableCollection<T>учебный класс.Классы моделей обычно обеспечивают проверку данных и отчеты об ошибках через
IDataErrorInfoили жеINotifyDataErrorInfoинтерфейсы.Классы модели обычно используются вместе со службой или хранилищем, которое инкапсулирует доступ к данным и кэширование.
Я написал это примерно так же, как "простой английский", как я могу представить в этой серии о MVVM. В частности, эта диаграмма, вероятно, самое простое, краткое объяснение.
При этом, по сути, "модель" - это ваши данные или бизнес-правила. Он действительно не должен знать о том, как или где он будет использоваться, и особенно не о том, какие технологии будут его использовать. "Модель" - это основные элементы приложения - и не нужно беспокоиться о том, является ли приложение WPF, Silverlight, Windows Forms, ASP.NET и т. Д., - это просто "само" в чистом виде.
"Вид" - это та часть, которая полностью зависит от технологии. В MVVM, в идеале, представление должно быть почти на 100% XAML, так как это обеспечивает огромный выигрыш в гибкости.
Тем не менее, должно быть что-то, что переводит информацию из Модели в какую-то форму, где ее можно использовать с помощью имеющихся технологий - именно здесь в игру вступает ViewModel. Например, это часто "оборачивает" классы модели в "ViewModel" для тех конкретных данных, которые включают в себя команды (для запуска логики), реализует INotifyPropertyChanged (для поддержки связывания данных) и т. д. Вот и все - это мост, который делает Модель доступной для представления.
Отличное введение в MVVM можно найти в видео Джейсона Долингера здесь. Я держал видео в течение долгого времени, когда я начинал, это действительно полезно.
Построение ViewModel, представляющего согласованный фасад поверх базовой Модели, может быть намного сложнее, чем кажется. Эта статья о построении объектов ViewModel демонстрирует, как построить ViewModel, и иллюстрирует некоторые проблемы, с которыми вы можете столкнуться, а также то, что выглядит как разумные решения. Когда я прочитал его, раздел о работе с коллекциями отсутствовал, но все же получил некоторые интересные моменты.