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

Question

Почему мы идем для MVVM над MVC или MVP при работе с WPF?

Какую дополнительную выгоду мы получаем, используя это?

Edit:

Честно говоря, сегодня у меня было интервью, и я задал этот вопрос. Я ответил как INotifyPropertyChanged, ICommand, IValue Convertor .. но он не был удовлетворен. Отныне я поставить этот вопрос

Заранее спасибо

Answer 1

Я укажу вам на особенно полезный video от Джейсона Долинджера.

Из мира WinForms, реализующего любой шаблон стиля MVX, казалось, было больше хлопот, чем это было необходимо, но после работы с WPF на пару лет я могу честно сказать, что я не буду рассматривать ничего меньшего. Вся парадигма поддерживается в готовом виде.

Прежде всего, ключевым преимуществом является возможность истинного разделения между «представлением» и «моделью».То, что это означает в реальном выражении, состоит в том, что если/когда ваша модель должна измениться, она может без необходимости просмотра и наоборот.

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

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

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

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

Удачи.

Answer 2

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

Answer 3

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

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

Answer 4

Это мои конкретным для MVVM

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

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

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

Answer 5

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

Answer 6

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

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

• DependencyProperty
• INotifyPropertyChanged
• ObservableCollection

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

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

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

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

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