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

пытаясь понять концепции MVVM, я уже прочитал несколько блогов и посмотрел на несколько проектов.

насколько я понимаю, a посмотреть немой, он просто знает, как представить то, что передается ему.

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

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

спасибо :)

5 64
mvvm

5 ответов:

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

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

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

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

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

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

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

101

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

View:

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

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

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

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

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

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

Модель Вид:

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

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

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

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

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

модель:

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

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

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

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

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

15

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

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

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

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

14

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

2

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

0