Почему MVVM и какие основные преимущества?

Ответ 1

Я расскажу вам о особенно полезном

Во-вторых, хотя ваша "модель" может содержать все данные, которые могут вам понадобиться в вашем "представлении", вы можете абстрагировать эти данные таким образом, чтобы ваша "модель" не поддерживала. Например, предположим, что ваша модель содержит свойство даты. В модели он может существовать только как объект DateTime, но ваше представление может представить его совершенно по-другому. Без "viewmodel" вам придется либо дублировать свойство в "модели", чтобы поддерживать представление, либо изменять свойство, которое может серьезно запутать "модель" .

Вы также можете использовать "viewmodel" для агрегирования частей вашей модели, которые существуют в отдельных классах/библиотеках, чтобы облегчить более свободный интерфейс для "представления". Это очень маловероятно, что вы захотите работать с данными в своем коде так же, как пользователь захочет или захочет, чтобы эти данные были представлены им.

Кроме того, вы получаете поддержку автоматической двусторонней привязки данных между "view" и "viewmodel" .

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

Удачи.

Ответ 2

Это мои специфические для MVVM

• Увеличивает "Смешиваемость" ваших просмотров (возможность использования Expression Blend для создания представлений). Это позволяет разделять обязанности на команды, которым посчастливилось иметь разработчика и программиста... каждый из них может работать независимо друг от друга.
• "Бесшумная" логика просмотра. Представления являются агностическими из кода, который выполняется за ними, что позволяет использовать одну и ту же логику представления в нескольких представлениях или легко просматривать или заменять представление. Различают проблемы между "поведением" и "стилем".
• Нет дублированного кода для обновления представлений. При кодировании кода вы увидите много запросов на "myLabel.Text = newValue", посыпанных повсюду. С MVVM вы можете быть уверены, что представление обновляется соответствующим образом, просто устанавливая базовое свойство и все его побочные эффекты.
• Тестируемость. Поскольку ваша логика полностью агностична для вашего представления (нет ссылок "myLabel.Text" ), модульное тестирование упрощается. Вы можете проверить поведение ViewModel без привлечения его представления. Это также позволило тестировать поведение поведения, основанное на тестах, что практически невозможно с использованием кода.

Другие два шаблона действительно являются отдельными с точки зрения проблем, которые они затрагивают. Вы можете использовать MVVM с MVP и MVC (большинство хороших образцов там делают какую-то форму).

На самом деле MVP (с пассивным представлением, а не надзорным контроллером) на самом деле является всего лишь вариантом MVVM, на мой взгляд.

Ответ 3

WPF имеет лучшую привязку данных, чем любая другая структура пользовательского интерфейса, которая MVVM будет непослушна без

MVVM обеспечивает единичную тестируемость и отличный обзор-агностицизм, что позволяет использовать

Ответ 4

Запеченные в поддержку ICommand и INotifyPropertyChanged являются двумя самыми большими преимуществами. Использование MVVM позволяет легко подключить команды и подключить данные к интерфейсу WPF. Все работает.

Ответ 5

Я лично вижу MVVM не как преимущество, а как обязательство для тех, кто хочет использовать интересные функции WPF.

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

• DependencyProperty
• INotifyPropertyChanged
• ObservableCollection

Из-за этого вы просто не можете написать модель так, как хотите, используя стандартную технологию .NET. Например, WPF TreeView практически невозможно использовать без использования привязки данных и шаблонов. Вы просто не можете заполнить его просто так, как если бы вы использовали общую модель в Winforms, например. Он должен быть привязан к иерархической модели с использованием ObservableCollection для представления дочерних элементов node.

Итак, пусть V представляет собой код XAML и его копию кода (поэтому он привязан к WPF как технология), и пусть M представляет вашу модель (так или иначе она не привязана к технологии интерфейса WPF).

Ну, у вас никогда не будет этой работы должным образом в WPF только с этими V и M.

Вы должны добавить что-то между ними. Что-то, что совместимо с WPF и понимает вашу модель. Что-то, что говорит DependencyProperty, ObservableCollection и INotifyPropertyChanged. Это то, что называется VM.

В качестве побочного примечания альтернативой MVVM является сборка V и M (без подключения к VM), при этом M является WPF-совместимым, но все еще с разумной независимостью пользовательского интерфейса. Исторически ObservableCollection был в сборке WindowsBase.dll(который был отправлен с WPF), поэтому было действительно странно связывать общую модель с чем-то, связанным с технологией пользовательского интерфейса. С тех пор он был возвращен в System.dll. Даже тогда, иногда трудно сохранить чистую модель VM без настройки M специально для WPF...

Ответ 6

Способность кода XAML к привязке к данным, а также наличие триггеров нарушают шаблоны MVP и MVC.