Хорошие примеры Шаблона MVVM

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

Выпуск призмы:
http://www.codeplex.com/CompositeWPF

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

Prism не обязательно для каждого проекта, но с ней полезно ознакомиться.

CRUD: Эта часть довольно проста, двусторонние привязки WPF позволяют очень легко редактировать большинство данных. Настоящая уловка состоит в том, чтобы предоставить модель, которая упрощает настройку пользовательского интерфейса. По крайней мере, вы хотите убедиться, что ваша ViewModel (или бизнес-объект) реализует INotifyPropertyChanged для поддержки привязки, и вы можете привязать свойства прямо к элементам управления пользовательского интерфейса, но вы также можете реализовать IDataErrorInfo для проверки. Обычно, если вы используете какое-то решение ORM, настроить CRUD несложно.

В этой статье демонстрируются простые грубые операции: http://dotnetslackers.com/articles/wpf/WPFDataBindingWithLINQ.aspx

Он построен на LinqToSql, но это не имеет отношения к примеру - все, что важно, это то, что ваши бизнес-объекты реализуют INotifyPropertyChanged (какие классы, сгенерированные LinqToSql, делают). MVVM не является предметом этого примера, но я не думаю, что это имеет значение в данном случае.

Эта статья демонстрирует проверку данных
http://blogs.msdn.com/wpfsdk/archive/2007/10/02/data-validation-in-3-5.aspx

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

В большинстве случаев вы можете взять объект (модель), созданный некоторым ORM, и обернуть его в ViewModel, который содержит его, и команды для сохранить / удалить - и вы готовы привязать пользовательский интерфейс прямо к свойствам модели.

Представление будет выглядеть примерно так (ViewModel имеет свойство Item , которое содержит модель, как класс, созданный в ORM):

<StackPanel>
   <StackPanel DataContext=Item>
      <TextBox Text="{Binding FirstName, Mode=TwoWay, ValidatesOnDataErrors=True}" />
      <TextBox Text="{Binding LastName, Mode=TwoWay, ValidatesOnDataErrors=True}" />
   </StackPanel>
   <Button Command="{Binding SaveCommand}" />
   <Button Command="{Binding CancelCommand}" />
</StackPanel>

Диалоги: Диалоги и MVVM немного сложны. Я предпочитаю использовать разновидность подхода Mediator с диалогами, вы можете прочитать об этом немного больше в этом вопросе StackOverflow:
Пример диалога WPF MVVM

Мой обычный подход, который не совсем классический MVVM, можно резюмировать следующим образом:

Базовый класс для диалоговой модели ViewModel, который предоставляет команды для действий фиксации и отмены, событие, позволяющее представление знает, что диалог готов к закрытию, и все, что вам понадобится во всех ваших диалогах.

Общее представление для вашего диалога - это может быть окно или настраиваемый «модальный» элемент управления наложением. По сути, это презентатор контента, в который мы выгружаем модель просмотра, и он обрабатывает проводку для закрытия окна - например, при изменении контекста данных вы можете проверить, унаследована ли новая модель просмотра от вашего базового класса, и если это так, подписаться на соответствующее событие закрытия (обработчик назначит результат диалога). Если вы предоставляете альтернативную универсальную функцию закрытия (например, кнопку X), Вы должны также убедиться, что выполнили соответствующую команду закрытия в ViewModel.

Где-то вам нужно предоставить шаблоны данных для ваших ViewModels, они могут быть очень простыми, тем более что у вас, вероятно, есть представление для каждого диалогового окна, инкапсулированного в отдельный элемент управления. Тогда шаблон данных по умолчанию для ViewModel будет выглядеть примерно так:

<DataTemplate DataType="{x:Type vmodels:AddressEditViewModel}">
   <views:AddressEditView DataContext="{Binding}" />
</DataTemplate>

Диалоговое представление должно иметь доступ к ним, потому что в противном случае оно не будет знать, как показать ViewModel, кроме общего диалогового UI, его содержимое в основном это:

<ContentControl Content="{Binding}" />

Неявный шаблон данных будет отображать представление в модель, но кто его запускает?

Это не совсем mvvm часть. Один из способов сделать это - использовать глобальное событие. Я думаю, что лучше всего использовать настройку типа агрегатора событий, предоставляемую посредством внедрения зависимостей - таким образом, событие является глобальным для контейнера, не все приложение. Prism использует структуру единства для семантики контейнера и внедрения зависимостей, и в целом мне очень нравится Unity.

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

Настройка этого способа позволяет ViewModels запрашивать приложение, чтобы открыть диалоговое окно и реагировать на действия пользователя в нем, ничего не зная о пользовательском интерфейсе, поэтому по большей части MVVM-ность остается завершенным.

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

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

ButtonClickHandler(sender, args){
    var vm = DataContext as ISomeDialogProvider; // check for null
    var ui_vm = new ViewModelContainer();
    // assign margin, width, or anything else that your custom dialog might require
    ...
    ui_vm.ViewModel = vm.SomeDialogViewModel; // or .GetSomeDialogViewModel()
    // raise the dialog show event
}

Представление диалогового окна привязывается к данным положения и передает содержащуюся в нем ViewModel во внутренний ContentControl . Сама ViewModel по-прежнему ничего не знает о пользовательском интерфейсе.

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

Итак, вместо этого потока:

// in code behind
var result = somedialog.ShowDialog();
if (result == ...

Я использую:

// in view model
var vm = new SomeDialogViewModel(); // child view model
vm.CommitAction = delegate { this.DoSomething(vm); } // what happens on commit 
vm.CancelAction = delegate { this.DoNothing(vm); } // what happens on cancel/close (optional)
// raise dialog request event on the container

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