使用MVVM设计模式构建WPF应用程序

本文是翻译大牛Josh Smith的文章,WPF Apps With The Model-View-ViewModel Design Pattern,译者水平有限,如有什么问题请看原文,或者与译者讨论(非常乐意与你讨论)。


本文讨论的内容:

WPF与设计模式

MVP模式

对WPF来说为什么MVVM是更好的选择

用MVVM构建WPF程序

本文涉及的技术:

WPF、数据绑定


内容列表

有序与混乱

模型-视图-视图模型的演变

为什么WPF开发者喜欢MVVM

演示程序

中继命令逻辑

ViewModel类层级结构

ViewModelBase类

CommandViewModel类

MainWindowViewModel类

View对应ViewModel

数据模型和Repository

新增客户数据表单

所有客户视图

总结


开发UI,对一个专业软件并不容易。它需要未知数据、交互式设计,可视化设计、联通性,多线程、国际化、验证、单元测试以及其他的一些东西才能完成。考虑到UI要展示开发的系统并且必须满足用户对系统风格不可预知的变更,因此它是很多应用程序最脆弱的地方。

有很多的设计模式可以帮助解决UI不断变更这头难缠的野兽,但是恰当的分离和描述多个关注点可能很困难。模式越复杂,之后用到的捷径越可能破坏之前正确的努力。

这并不总是设计模式的错。有时使用要写很多的代码复杂设计模式,这是因为我们使用的UI平台并不适合简单是设计模式。UI平台需要做的是很容易使用简单的,久经考验的,开发者认识的设计模式构建UI。庆幸的是,WPF就是这样一个平台。

随着是使用WPF开发的比例不断升高,WPF社区发展了自己的模式与实践生态圈子。在本文,我将讨论一些设计与实现客户端应用程序的WPF最佳实践。利用WPF和MVVM设计模式衔接的一些核心功能,我将通过一个例子介绍,用“正确”的方式构建一个WPF程序是多么的简单。

data templates, commands, data binding, the resource system以及 MVVM 模式怎么揉合到一起创建一个简单的、可测试的、健壮的框架,并且任何WPF程序都能使用,到文章最后,这一切都很清晰明了。文中的例程可以作为现实中一个WPF应用程序的模版,并且使用MVVM设计模式作为其核心架构。例程解决方案中的单元测试部分,展示了测试ViewModel类的功能是很容易的。在深入本文之前,我们首先看一下我们要使用像MVVM这样的设计模式。

有序与混乱

没有必要在一个”Hello,World!”的程序中使用设计模式。任何一个合格的开发者看一眼就指导那几行代码是干什么的。然而随着程序功能点的增加,随之代码的数量以及移动部件也会增多。最终系统的复杂度以及不断出现问题,促使开发者组织他们的代码,以便它们更容易理解,讨论、扩展以及维护。我们通过给代码中某些实体命以众所周知的名字,减少复杂系统认知误区。我们给函数块命名主要依据系统中的功能角色。

开发者有意识的根据设计模式组织他们的代码,而不是根据设计模式自动去组织。无论哪一种,都没有什么问题。但是在本文中,我说明在WPF程序中明确使用MVVM模式的好处。

某些类的名称,包括MVVM模式中著名的术语,如果类是view的抽象类就以ViewModel结束。这种方式有助于避免之前提到的认知误区。相反,你也可以让那种受控的误区存在,这正是大部分软件开发项目的自热状态。

模型-视图-视图模型的演变

自从人们开始构建UI时,就有很多流行的设计模式让UI构建更容易。比如,MVP模式在各种UI编程平台中都非常流行。MVP是MVC模式的一种变体,MVC模式已经流行了几十年了。以防你之前从没用过MVP模式,这里做一个简单的解释。你在屏幕上看到的是View,它显示的数据是Model,Presenter就是把两者联系起来。View依赖Presenter并通过Presenter展示Model数据,响应用户输入,提供数据验证(或许委托给Model去完成)以及其他的一些任务。如果你想了解更过关于MVP模式,我建议你去读Jean-Paul Boodhoo的 August 2006 Design Patterns column

2004年晚些时候,Martin Fowler发表了一篇叫Presentation Model(PM)的模式。PM模式和MVP类似,MVP是把一个View从行为和状态分离出来。PM中令人关注的部分是创建view的抽象,叫做Presentation Model。之后,View就仅仅是Presentation Model的展示了。在Fowler的论文中,他展示了Presentation Model经常更新View,以便两个彼此同步。同步逻辑组作为代码存在于Presentation Model类中。

2005年,John Gossman,目前是微软WPF和Silverlight架构师,在他的博客上披露了Model-View-ViewModel (MVVM)模式。MVVM和Fowler的Presentation Model是一致的,两个模式的特征都是View的抽象,都包含了View的行为和状态。Fowler引入Presentation Model是作为创建独立平台的View的抽象,而Gossman引入MVVM是作为标准化的方法,利用WPF的核心特点去简化UI的创建。从这种意义上来讲,我把MVVM作为一般PM模式的一个特例。

在Glenn Block一遍优秀的文章"Prism: Patterns for Building Composite Applications with WPF",于2008年9月微软大会发布,他解释了WPF微软组合程序开发向导。术语ViewModel没有用到,然而PM却用来描述View的抽象。这篇文章自始至终,都没没有出现我要将MVVM模式,以及View的抽象ViewModel。我发现这个术语在WPF和Silverlight社区中比较流行。

不像MVP中的Presenter,ViewModel不需要引用View。View 绑定ViewModel的属性,ViewMode向Viewl暴露Model对象的数据以及其他的状态。View和ViewModel之间的绑定很容易构造,因为ViewModel对象可以设置为View的DataContext。如果ViewModel中的属性值发生改变,新值将通过绑定自动传送给View。当用户点击View中的按钮时,ViewMode对于的Command将执行请求的动作。ViewModel,绝不是View,去执行实体对象的修改。

View类并不知道Model类是否存在,同时ViewModel和Model也不知道View。实际上,,Model完全不知道ViewModel和View存在,这是一个非常松耦合的设计,在很多方面都有好处,这不就你就会看到。

为什么WPF开发者喜欢MVVM

一旦开发者适应了WPF和MVVM,就很难区别两者。因为MVVM非常适合WPF平台,并且WPF被设计使用MVVM模式更容易构建应用程序,MVVM就成了WPF开发者的通用语。事实上,微软内部正在用MVVM开发WPF应用程序,像Microsoft Expression Blend,然而当时WPF平台的核心功能依然在开发之中。WPF的很多方面,像控制模型以及数据模版,都利用了MVVM推荐的显示状态和行为分离技术。

MVVM之所以成为一个伟大设计模式,是因为WPF的一个最重要的特征数据绑定构造。通过把Viewde 属性绑定到ViewModel,你就可以得到两者松耦合的设计,并且完全去除ViewModel更新View的那部分代码。数据绑定系统支持输入验证,并且输入验证提供了传递错误给View的标准方法。

另两个WPF的特点,数据模版和资源系统让MVVM模式更加可用。数据模版把View应用在ViewModel对象上,以便其能够在UI上显示。你可以在Xaml中声明模版,让资源系统在系统运行过程中自动定位并应用这些模版。你可以从我2008年7月写的一篇文章, "Data and WPF: Customize Data Display with Data Binding and WPF.",获取更多关于绑定和数据模版的信息。

要不是WPF对Command的支持,MVVM模式就不会那么强大。本文中,我会为你展示ViewModel怎样把Commands暴露给View,并且让View消费它的功能。如果你对Command不是很熟悉,我推荐你读一下2008年9月Brian Noyes发布的文章, "Advanced WPF: Understanding Routed Events and Commands in WPF"。

除了WPF(Silverlight2)本身让MVVM以一种自然的方式去构建程序之外,造成MVVM模式流行还有一个原因,那就是ViewModel类很容易进行单元测试。从某种意义来讲,View和单元测试只是ViewModel两个不同类型的消费者。拥有一套应用程序的单元测试,可以为提供更自由、快速的回归测试,而回归测试有助于降低之后应用的维护成本。

除了促进创建自动化回归测试外,ViewModel类的可测试性也有助于设计更容易分离的UI。当你设计应用时,你可以通过想象某些东西是否要创建单元测试消费ViewModel,来确定它们是放到View里面还是ViewModel里面。如果你可以为ViewModel写单元测试而不用创建任何UI控件,你也可以把ViewModel剥离出来,因为它不依赖任何具体可视化的组件。

最后,对于要和设计者合作的开发者来说,使用MVVM模式使得创建平滑的开发/设计工作流更加容易。既然View可以是ViewModel的任意一个消费者,就很容易去掉一个View通过新增一个View去渲染ViewModel。这个简单的步骤允许设计师构建快速原型以及评估UI设计。

这样开发团队可以关注创建健壮的ViewModel类,而设计团队可以关注设计界面友好的View。要融合两个团队输出只需要在View的xaml上进行正确的绑定即可。

演示程序

到此为止,我们回顾了MVVM的历史以及具体操作理论。我也说明了它在WPF开发者中间如此流行的原因。现在是时候继续我们的步伐,看一下MVVM模式在实际中的应用。这篇文章中的演示程序以各种方式使用MVVM设计模式,它提供了丰富的例子,帮助在上下文中理解MVVM的概念。我用VS2008 SP1创建的这个演示程序, 框架是Microsoft .NET Framework 3.5 SP1。单元测试是用的Visual Studio unit testing。

应用可以包含任意数量的“Workspace”,每一个都可以由用户点击左侧导航区的命令链接打开。所有的Workspace寄宿在主区域TabControl中,用户可以通过点击workspace的 tab item上关闭按钮关闭workspace。应用程序有两个可用的workspace:"All Customers" 和 "New Customer"。运行程序,打开一些workspace,UI看起来如图1所示。

clip_image002

图1 Workspaces

一次只有一个“All Customers“ Workspace的实例可以打开,但是可以打开多个New Customer Workspace。当用户决定创建一个新的客户时,她必须填完图2所示的数据输入表单。

clip_image003

图2 新客户数据输入表单

填完数据输入表单的所有有效值点击“Save”按钮,新客户的名称将会出现在tab item 上面,同时新客户也会增加到客户列表中。应用程序不支持删除或者编辑客户,但是这和其它功能类似,很容易在已有的程序架构上去实现。现在你已经对演示程序有了更深层次的理解了,接下来我们研究它是如何设计以及实现的。

中继命令逻辑Relaying Command Logic)

除了类构造器里调用初始化组件标准的样板代码,应用中的每一View的codebehind文件都是空的。实际上你可以移除View的codebehind文件,程序让人能够争正确的编译和运行。尽管View中没有事件处理方法,但是当用户点击按钮时,程序依然能够响应并满足用户的请求。之所以这样,是因为UI上Hyperlink、 Button以及MenuItem控件的Command属性被绑定了。绑定机制确保当用户在控件上点击时,由ViewModel暴露的ICommand对象能够执行。你可以把command对象看作一个适配器,这个适配器让command对象很容易消费在View中声明的ViewModel功能。

当ViewModel暴露ICommad类型的实例属性,被暴露的Command对象使用ViewModel中的对象去完成它的工作。其中一个可能的实现模式是在ViewModel内创建一个私有嵌套类,以便command能够访问包含在ViewModel中的私有成员,而不至于污染命名空间。嵌套类实现了ICommand接口,包含在ViewModel中对象的引用注入到其构造器中。但是为ViewModel暴露的每个Command创建实现ICommad的嵌套类,会增加ViewModel类的大小。更多的代码意味着存在BUGS潜力更大。

在演示程序中,RelayCommand类解决了这个问题。RelayCommand允许通过把委托传给其构造器,以实现对命令逻辑的注入。这种方式允许在ViewMode类中可以简单明了的实现Command。

RelayCommand是DelegateCommand的一个简单的变体,DelegateCommand可以在Microsoft Composite Application Library找到。RelayCommand类代码如图3所示。

图3 RelayCommand类

public class RelayCommand : ICommand
{
#region Fields
 
 
readonly Action<object> _execute;
readonly Predicate<object> _canExecute;
 
 
#endregion // Fields
 
 
#region Constructors
 
 
public RelayCommand(Action<object> execute)
this(execute, null)
{
}
 
 
public RelayCommand(Action<object> execute, Predicate<object> canExecute)
{
if (execute == null)
throw new ArgumentNullException("execute");
 
 
_execute = execute;
_canExecute = canExecute;
}
#endregion // Constructors
 
 
#region ICommand Members
 
 
[DebuggerStepThrough]
public bool CanExecute(object parameter)
{
return _canExecute == null ? true : _canExecute(parameter);
}
 
 
public event EventHandler CanExecuteChanged
{
add { CommandManager.RequerySuggested += value; }
remove { CommandManager.RequerySuggested -= value; }
}
 
 
public void Execute(object parameter)
{
_execute(parameter);
}
 
 
#endregion // ICommand Members
}

作为接口ICommad实现一部分,事件CanExecuteChanged有一些值得关注的特征。它委托订阅CommandManager. RequerySuggested事件。这样以确保无论何时调用内置命令时,WPF命令架构都能调用所有能够执行的RelayCommand对象。

RelayCommand _saveCommand;
public ICommand SaveCommand
{
get
{
if (_saveCommand == null)
{
_saveCommand = new RelayCommand(param => this.Save(),
param => this.CanSave );
}
return _saveCommand;
}
}

ViewModel类层级图

大部分ViewModel类有共同的特征,他们要实现INotifyPropertyChanged接口,需要显示一个友好的名字,以之前说道Workspace为例,它需要能够关闭(即从UI上移除)。要解决这个问题,自然就需要创建一个或二个ViewModel基类,以便新的ViewModel类能够从基类集成通用的功能。所有的ViewModel类形成如图4的层级图。

clip_image004

图4 继承层级图

为你的ViewModel创建一个基类并不是必须。如果你喜欢在类中通过组合几个小一点的类以获得那些功能,而不是用继承的方式,这并没有什么问题。就像任何其他的设计模式一样,MVVM是一套指导方针,而不是规则。

ViewModelBase 类

ViewModelBase 是层级中的根类,这就是它要实现通用INotifyPropertyChanged接口以及有一个DisplayName属性的原因。INotifyPropertyChanged接口包含一个叫PropertyChanged的事件。无论何时ViewModel对象的属性的发生改变时,它都会触发PropertyChanged事件,把新值通知给WPF绑定系统。根据通知,绑定系统检索属性,UI组件上绑定的属性将接受新值。

为了让WPF知道是那一个属性发生了改变,PropertyChangedEventArgs类暴露了一个string类型的属性PropertyName 。你一定要为事件参数传递正确的属性名,否则WPF将会为新值检索出一个错误的属性。

ViewModelBase一个值得关注的地方就是它为给定的属性名提供了验证,验证属性是否存在ViewModel对象上。重构时,这非常有用。因为通过VS 2008重构功能去改变属性名,不会更新源代码中字符串,而这些字符串正好包含属性名(其实不应该包含)。在事件参数中传递不正确的属性名,触发PropertyChanged事件时,可能会导致微小的BUGs,并且这些BUGs很难追踪,因此这个细微的特征将会节省大量的时间。ViewModelBase中增加了这个有用的特征,其代码如下:

图5 属性验证

// In ViewModelBase.cs
public event PropertyChangedEventHandler PropertyChanged;
 
 
protected virtual void OnPropertyChanged(string propertyName)
{
this.VerifyPropertyName(propertyName);
 
 
PropertyChangedEventHandler handler = this.PropertyChanged;
if (handler != null)
{
var e = new PropertyChangedEventArgs(propertyName);
handler(this, e);
}
}
 
 
[Conditional("DEBUG")]
[DebuggerStepThrough]
public void VerifyPropertyName(string propertyName)
{
// Verify that the property name matches a real,
// public, instance property on this object.
if (TypeDescriptor.GetProperties(this)[propertyName] == null)
{
string msg = "Invalid property name: " + propertyName;
 
 
if (this.ThrowOnInvalidPropertyName)
throw new Exception(msg);
else
Debug.Fail(msg);
}
}

CommandViewModel 类

CommandViewModel是最简单的ViewModelBase子类,它暴露了一个类型为ICommad的Command属性。MainWindowViewModel通过Commands属性暴露了CommandViewModel对象的一个集合。主窗口左手侧的导航区域,显示了MainWindowView­Model暴露每个CommandViewModel对象链接,像“View all customers”和“Create new customer”。当用户点击链接,将会执行相应的Command,在主窗口的TabControl中打开一个workspace。CommandViewModel类的定义如下所示:

public class CommandViewModel : ViewModelBase
{
public CommandViewModel(string displayName, ICommand command)
{
if (command == null)
throw new ArgumentNullException("command");
 
 
base.DisplayName = displayName;
this.Command = command;
}
 
 
public ICommand Command { get; private set; }
}

在MainWindowResources.xaml文件中存在一个key为CommandsTemplate的数据模版,主窗口(MainWindow)使用这个模版渲染之前提到的CommandViewModel对象集合。这个模版是简单在ItemsControl里把每个CommandViewModel对象渲染成一个链接,每个链接的Command属性绑定到CommandViewModel对象的Command属性。数据模版Xaml如图6所示:

图6 渲染Command列表

<!-- In MainWindowResources.xaml -->
<!--
This template explains how to render the list of commands on
the left side in the main window (the 'Control Panel' area).
-->
<DataTemplate x:Key="CommandsTemplate">
<ItemsControl ItemsSource="{Binding Path=Commands}">
<ItemsControl.ItemTemplate>
<DataTemplate>
<TextBlock Margin="2,6">
<Hyperlink Command="{Binding Path=Command}">
<TextBlock Text="{Binding Path=DisplayName}" />
</Hyperlink>
</TextBlock>
</DataTemplate>
</ItemsControl.ItemTemplate>
</ItemsControl>
</DataTemplate>

MainWindowViewModel 类

如前面看到的类图一样,WorkspaceViewModel类继承于ViewModelBase并增加了“关闭”的能力。这个“关闭”,我的意思是在运行的时候能把workspace从UI上移除。有三个类继承于WorkspaceViewModel,他们分别为MainWindowViewModel,AllCustomersViewModel和CustomerViewModel。MainWindowViewModel的关闭请求是由App类处理的,其中App类创建了MainWindow以及它对应的ViewModel对象。创建代码如图7所示.

图7 创建ViewModel

// In App.xaml.cs
protected override void OnStartup(StartupEventArgs e)
{
base.OnStartup(e);
 
 
MainWindow window = new MainWindow();
 
 
// Create the ViewModel to which
// the main window binds.
string path = "Data/customers.xml";
var viewModel = new MainWindowViewModel(path);
 
 
// When the ViewModel asks to be closed,
// close the window.
viewModel.RequestClose += delegate
{
window.Close();
};
 
 
// Allow all controls in the window to
// bind to the ViewModel by setting the
// DataContext, which propagates down
// the element tree.
window.DataContext = viewModel;
 
 
window.Show();
}

MainWindow包含一个菜单项,该菜单项的Command属性绑定到MainWindowViewModel上的CloseCommand属性上。当用户点击该菜单,App类响应请求,调用窗体的关闭方法。菜单Xaml如下所示:

<!-- In MainWindow.xaml -->
<Menu>
<MenuItem Header="_File">
<MenuItem Header="_Exit" Command="{Binding Path=CloseCommand}" />
</MenuItem>
<MenuItem Header="_Edit" />
<MenuItem Header="_Options" />
<MenuItem Header="_Help" />
</Menu>

MainWindowViewModel包含了WorkspaceViewModel对象一个observable类型的集合,该集合的名称为Workspaces。主窗体包含了一个TabControl,其ItemsSource绑定到上述的集合。每一个tab item都有一个关闭按钮,其Command属性绑定到它对应WorkspaceViewModel实例的CloseCommand上。模版展示了如何渲染一个带关闭按钮的tab item。配置tab item模版的简化版会展示在下面代码中,这段代码可以在MainWindowResources.xaml文件中找到。

<DataTemplate x:Key="ClosableTabItemTemplate">
<DockPanel Width="120">
<Button
Command="{Binding Path=CloseCommand}"
Content="X"
DockPanel.Dock="Right"
Width="16" Height="16"
/>
<ContentPresenter Content="{Binding Path=DisplayName}" />
</DockPanel>
</DataTemplate>

当用户点击tab item上的关闭按钮时,会执行Workspace­ViewModel的CloseCommand,触发它的Request­Close事件。MainWindowViewModel会监控workspace的Request­Close事件,根据请求从Workspaces集合中移除相应的workspace。因为Main­Window的TabControl的ItemsSource绑定到Workspace­ViewModel的observable集合,从集合中移除对象,会引起从TabControl中移除相应的workspace。Main­WindowViewModel相应的逻辑如图8所示

图8 从UI上移除workspace

// In MainWindowViewModel.cs
 
 
ObservableCollection<WorkspaceViewModel> _workspaces;
 
 
public ObservableCollection<WorkspaceViewModel> Workspaces
{
get
{
if (_workspaces == null)
{
_workspaces = new ObservableCollection<WorkspaceViewModel>();
_workspaces.CollectionChanged += this.OnWorkspacesChanged;
}
return _workspaces;
}
}
 
 
void OnWorkspacesChanged(object sender, NotifyCollectionChangedEventArgs e)
{
if (e.NewItems != null && e.NewItems.Count != 0)
foreach (WorkspaceViewModel workspace in e.NewItems)
workspace.RequestClose += this.OnWorkspaceRequestClose;
 
 
if (e.OldItems != null && e.OldItems.Count != 0)
foreach (WorkspaceViewModel workspace in e.OldItems)
workspace.RequestClose -= this.OnWorkspaceRequestClose;
}
 
 
void OnWorkspaceRequestClose(object sender, EventArgs e)
{
this.Workspaces.Remove(sender as WorkspaceViewModel);
}

在UnitTests项目中,MainWindowViewModelTests.cs文件包含了一个测试方法,该方法验证上述功能是否正确执行。很容易为ViewModel类创建单元测试是MVVM模式的一个大卖点,因为它只需测试应用程序的功能,而不用写和UI交互的代码。上述测试方法图9所示

图9 测试方法

// In MainWindowViewModelTests.cs
[TestMethod]
public void TestCloseAllCustomersWorkspace()
{
// Create the MainWindowViewModel, but not the MainWindow.
MainWindowViewModel target =
new MainWindowViewModel(Constants.CUSTOMER_DATA_FILE);
 
 
Assert.AreEqual(0, target.Workspaces.Count, "Workspaces isn't empty.");
 
 
// Find the command that opens the "All Customers" workspace.
CommandViewModel commandVM =
target.Commands.First(cvm => cvm.DisplayName == "View all customers");
 
 
// Open the "All Customers" workspace.
commandVM.Command.Execute(null);
Assert.AreEqual(1, target.Workspaces.Count, "Did not create viewmodel.");
 
 
// Ensure the correct type of workspace was created.
var allCustomersVM = target.Workspaces[0] as AllCustomersViewModel;
Assert.IsNotNull(allCustomersVM, "Wrong viewmodel type created.");
 
 
// Tell the "All Customers" workspace to close.
allCustomersVM.CloseCommand.Execute(null);
Assert.AreEqual(0, target.Workspaces.Count, "Did not close viewmodel.");
}

把View应用到ViewModel上

MainWindowViewModel间接从主窗体的Tab­Control控件中增加移除Workspace­ViewModel对象。通过数据绑定,TabItem的Content属性显示继承于ViewModelBase的对象。ViewModelBase并不是一个UI元件,因此他并不支持渲染它自己。默认在TextBlock中,WPF的一个非可视化对象通过调用ToString方法以显示该对象。很明显这不是你想要的,除非你的用户迫切的想知道ViewModel的类型名。

我们通过强类型数据模版很容易告诉WPF如何渲染ViewModel对象。强类型数据模版key属性名没有赋值,但是其DataType属性要赋以类型类的实例。如果WPF要去渲染ViewModel对象,它会检查在资源系统范围内是否有一个强类型数据模版的DataType和ViewModel对象(或者其基类)的类型一样。如果找到一个这样的模版的话,他会用该模版去渲染被TabItem Content属性绑定的ViewModel对象。

MainWindowResources.xaml文件中有一个Resource­Dictionary(资源字典),该字典被增加到主窗体的资源层级中,这意味着文件包含的资源在正窗体范围内有效。当一个TabItem的Content属性设置ViewModel对象时,该字典中的强类型数据模版会提供一个View(即用户自定义控件)去渲染TabItem Content。具体如图10所示

图10 提供View

<!--
This resource dictionary is used by the MainWindow.
-->
<ResourceDictionary
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:vm="clr-namespace:DemoApp.ViewModel"
xmlns:vw="clr-namespace:DemoApp.View"
>
 
 
<!--
This template applies an AllCustomersView to an instance
of the AllCustomersViewModel class shown in the main window.
-->
<DataTemplate DataType="{x:Type vm:AllCustomersViewModel}">
<vw:AllCustomersView />
</DataTemplate>
 
 
<!--
This template applies a CustomerView to an instance
of the CustomerViewModel class shown in the main window.
-->
<DataTemplate DataType="{x:Type vm:CustomerViewModel}">
<vw:CustomerView />
</DataTemplate>
 
 
<!-- Other resources omitted for clarity... -->
 
 
</ResourceDictionary>

你不需要写任何代码去决定哪一个View去展示ViewModel对象。WPF资源系统把你从繁重的工作解脱出来,让你去关注更重要的事情。在复杂的场景中,可能需要通过编程去选择View,但是在大部分情况下,通过编程选择View是不必要的。

The Data Model and Repository 数据模型和存储库

你已经知道应用程序如何去加载,显示以及关闭一个ViewModel对象。现在一切已经就位,你可以在整个应用程序范围内,回顾一下具体实现的细节。在深入理解应用程序的两个workspace,“All Customers” 和 “New Customer”之前,我们先审视一下数据模型和数据存取类。这些类的设计和MVVM模式并没有什么关系,因为你可以创建一个ViewModel类,以适应任何对WPF友好的数据对象。

演示程序中唯一的模型类Customer类,该类有些属性表征一个公司的客户,像他们的姓名,email等。它通过实现IDataErrorInfo接口提供属性验证信息,该接口在WPF大行其道之前已存在多年。Customer类里面并没有什么,并不是建议其用于MVVM架构,或者甚至应用和WPF应用程序。这个类很容易从遗留的业务库中获取。

数据必须存到某个地方,在这个应用程序中,CustomerRepository类的实例加载并存储所有的Customer对象。该CustomerRepository从xml文件加载所有的客户数据,这与外部的数据源无关。数据可能来自数据库、Web服务、命名管道、磁盘上的文件甚至信鸽,这并没有什么关系。只要你有一个有数据.net对象,不管它来自何方,MVVM模式都能在屏幕上获取其包含数据。

CustomerRepository类暴露了一些方法,这些方法允许你获取所有的Customer对象,增加一个Customer对象到存储室并检查其子啊存储室是否存在。既然应用程序不允许删除客户,存储室也不允许你去删除客户。当一个新Customer通过AddCustomer方法增加到CustomerRepository时,会触发CustomerAdded事件。

很明显,和真实业务程序所需的相比,该程序的数据模型是轻量级的,但是这并没有关系。重要的是,要理解ViewModel类如何利用Customer和CustomerRepository类。知道Customer­ViewModel是对Customer对象的封装,其通过一系列的属性暴露了Customer的状态,以及被Customer­View使用的状态。CustomerViewModel并不是复制Customer对象的状态,而是通过委托暴露这状态,具体如下:

public string FirstName
{
get { return _customer.FirstName; }
set
{
if (value == _customer.FirstName)
return;
_customer.FirstName = value;
base.OnPropertyChanged("FirstName");
}
}

当用户在CustomerView控件中创建新客户点击保存按钮时,与该视图关联的CustomerViewModel会增加一个Customer对象到Customer­Repository 。这会触发存储库的CustomerAdded事件,该事件让AllCustomers­ViewModel知道他应该增加一个Customer­ViewModel对象到AllCustomers集合。从某种意义说,Customer­Repository在各自ViewModel和他们要处理的Customer对象间扮演数据同步的角色,或许有人会把这当成中介者模式。我会在接下来的内容中介绍其实现机理,但是为了更进一步了解这些类如何连接在一起,我们现在先看一下图11所示的类图

clip_image006

图11 Customer关系图

New Customer Data Entry Form新客户数据输入表单

当用户点击“Create new customer”链接,MainWindowViewModel会增加一个CustomerViewModel到workspaces集合,相应的CustomerView回去显示。用户在输入框输入有效值之后,Save按钮变为可用状态,以便用户能存储增加客户信息。这并没有超出常规的地方,只是一个带有验证信息和Save按钮的常规输入表单而已。

Customer类内置输入验证支持,这是通过实现IDataErrorInfo接口获得。输入验证确保客户有一个名字,合法的email地址,如果客户是个人客户,还需要姓氏。如果Customer对象的IsCompany属性为真,则其LastName属性不能有值。该验证逻辑从Customer对象的角度看是有意义的,但是它并不能满足UI的需要,UI要求用户选择客户类别是个人还是公司。Customer类别选择器初始值是: (Not Specified),如果Customer对象的IsCompany属性只允许是true和false,客户类别是unspecified时,UI如何告诉用户?

假定你对整个软件系统拥有控制权限,你可以把IsCompany属性类型改变为Nullable<bool>,该类型允许“未选择”值(即空值-译者注)。然而在现实世界中,不是这么简单。假设你不能改变Customer类,因为它来自公司其他团队所开发系统。要是因为数据库的原因,没有简单方法存储未选择的值,怎么办?要是其它程序已经使用Customer类,并且其依赖正常Boolean类型的IsCompany属性,怎么办?诸如此类,可以使用ViewModel去解决。

图12所示的测试方法展示了该功能如何在CustomerViewModel中工作,CustomerViewModel暴露了一个CustomerTypeOptions属性,以便UI上的客户类型选择器有三个字符串显示。同时它也暴露了一个CustomerType属性,该属性存放选择器选中的字符串。当CustomerType被赋值时,它会潜在的Customer对象IsCompany属性,把字符类型转化为Boolean类型。图13展示了这两个属性。

图12 测试方法

// In CustomerViewModelTests.cs
[TestMethod]
public void TestCustomerType()
{
Customer cust = Customer.CreateNewCustomer();
CustomerRepository repos = new CustomerRepository(
Constants.CUSTOMER_DATA_FILE);
CustomerViewModel target = new CustomerViewModel(cust, repos);
 
 
target.CustomerType = "Company"
Assert.IsTrue(cust.IsCompany, "Should be a company");
 
 
target.CustomerType = "Person";
Assert.IsFalse(cust.IsCompany, "Should be a person");
 
 
target.CustomerType = "(Not Specified)";
string error = (target as IDataErrorInfo)["CustomerType"];
Assert.IsFalse(String.IsNullOrEmpty(error), "Error message should
be returned");
}

图13 CustomerTypeOptions和CustomerType

// In CustomerViewModel.cs
 
 
public string[] CustomerTypeOptions
{
get
{
if (_customerTypeOptions == null)
{
_customerTypeOptions = new string[]
{
"(Not Specified)",
"Person",
"Company"
};
}
return _customerTypeOptions;
}
}
public string CustomerType
{
get { return _customerType; }
set
{
if (value == _customerType ||
String.IsNullOrEmpty(value))
return;
 
 
_customerType = value;
 
 
if (_customerType == "Company")
{
_customer.IsCompany = true;
}
else if (_customerType == "Person")
{
_customer.IsCompany = false;
}
 
 
base.OnPropertyChanged("CustomerType");
base.OnPropertyChanged("LastName");
}
}

CustomerView用户控件中有一个ComboBox绑定这两个属性,如下所示:

<ComboBox
ItemsSource="{Binding CustomerTypeOptions}"
SelectedItem="{Binding CustomerType, ValidatesOnDataErrors=True}"
/>

当ComboBox中的选择项发生改变时,其数据源的将会扫描IDataErroInfo接口查看新值是否有效。之所以这样,是因为绑定的SelectedItem属性有一个ValidateOnDataErrors设置为true。既然数据源是一个CustomerViewModel对象,绑定系统会会向CustomerViewModel对象要求一个对CustomerType属性的验证信息。大多情况下,CustomerViewModel会把所有的验证请求委托给其包含的Customer对象。然而,因为Customer的IsCompany属性没有未选中状态的概念,所以CustomerViewModel必须对ComboBox中新选择项进行处理。具体代码如图14所示。

图14 验证CustomerViewModel对象

// In CustomerViewModel.cs
string IDataErrorInfo.this[string propertyName]
{
get
{
string error = null;
 
 
if (propertyName == "CustomerType")
{
// The IsCompany property of the Customer class
// is Boolean, so it has no concept of being in
// an "unselected" state. The CustomerViewModel
// class handles this mapping and validation.
error = this.ValidateCustomerType();
}
else
{
error = (_customer as IDataErrorInfo)[propertyName];
}
 
 
// Dirty the commands registered with CommandManager,
// such as our Save command, so that they are queried
// to see if they can execute now.
CommandManager.InvalidateRequerySuggested();
 
 
return error;
}
}
 
 
string ValidateCustomerType()
{
if (this.CustomerType == "Company" ||
this.CustomerType == "Person")
return null;
 
 
return "Customer type must be selected";
}

该部分代码重点在于CustomerViewModel实现了IDataErrorsInfo接口,可以处理对CustomerViewModel具体属性的验证请求,同时把其它请求委托给Customer对象处理。这样允许我们使用Model类的验证逻辑,其它属性验证在ViewModel类中才有意义。

通过SaveCommand属性去保存CustomerViewModel对象,该命令使用了之前陈述的RelayCommand,允许CustomerViewModel决定其是否能保存自己以及被告知保存其状态时做什么。在该程序中,保存一个新客户只是把其增加到CustomerRepository。决定一个新客户是否能够保存,需要两方面的许可,一是Customer对象是否有效,二是CustomerViewModel必须是有效的。这两方面是必要条件,由于前面陈述的ViewModel其特定属性以及Customer对象验证信息。CustomerViewModel的保存逻辑如图15所示

图15 CustomerViewModel的保存逻辑

// In CustomerViewModel.cs
public ICommand SaveCommand
{
get
{
if (_saveCommand == null)
{
_saveCommand = new RelayCommand(
param => this.Save(),
param => this.CanSave
);
}
return _saveCommand;
}
}
 
 
public void Save()
{
if (!_customer.IsValid)
throw new InvalidOperationException("...");
 
 
if (this.IsNewCustomer)
_customerRepository.AddCustomer(_customer);
 
 
base.OnPropertyChanged("DisplayName");
}
 
 
bool IsNewCustomer
{
get
{
return !_customerRepository.ContainsCustomer(_customer);
}
}
 
 
bool CanSave
{
get
{
return
String.IsNullOrEmpty(this.ValidateCustomerType()) &&
_customer.IsValid;
}
}

这里ViewModel的使用使得创建显示Customer对象的View更加容易,并且允许像Boolean类型未选中这样事情存在。同时它很容易告诉客户保存其状态。如果View直接绑定到Customer对象,View将会需要很多代码才能恰当的工作。在一个设计良好的MVVM架构中,大部分View的背后代码应该为空,或者最多只包含操纵View内的控件以及资源的代码。有时在View后面写一些代码也是必须的,因为要和ViewModel对象进行交互,像传递事件或者调用方法否则从ViewModel做些事情很难。

All Customers View

演示程序也包含了一个在ListView中显示所有客户列表的workspace。这些客户通过根据其是个人客户还是公司客户进行分组。用户一次可以选择一个或者多个客户,在右下方查看其总销售额。

该UI是AllCustomersView控件,用以渲染AllCustomersViewModel对象。每个ListView­Item代表一个CustomerViewModel对象,该对象存在于AllCustomerViewModel对象暴露的AllCustomers集合中。在前一部分,你看到CustomerViewModel如何渲染成数据输入表单,而现在一模一样的CustomerViewModel对象却被渲染成ListView中的一个Item。CustomerViewModel并不知道那一个可视化的组件去显示它,这使得其重用成为可能。

AllCustomersView创建了在ListView中看到的分组,这是通过把ListView的ItemsSource绑定到配置如图16所示的Collection­ViewSource中实现的。

图16 CollectionViewSource

<!-- In AllCustomersView.xaml -->
<CollectionViewSource
x:Key="CustomerGroups"
Source="{Binding Path=AllCustomers}"
>
<CollectionViewSource.GroupDescriptions>
<PropertyGroupDescription PropertyName="IsCompany" />
</CollectionViewSource.GroupDescriptions>
<CollectionViewSource.SortDescriptions>
<!--
Sort descending by IsCompany so that the ' True' values appear first,
which means that companies will always be listed before people.
-->
<scm:SortDescription PropertyName="IsCompany" Direction="Descending" />
<scm:SortDescription PropertyName="DisplayName" Direction="Ascending" />
</CollectionViewSource.SortDescriptions>
</CollectionViewSource>

ListViewItem和CustomerViewModel之间的关联是通过ListView的ItemContainerStyle属性建立的。指定给该属性的Style应用于每个ListViewItem,这使得ListViewItem的属性可以绑定到CustomerViewModel对象的属性上。这个Style一个重要的绑定就是在ListViewItem的IsSelected属性和CustomerViewModel的IsSelected属性之间建立的联系,如下所示:

<Style x:Key="CustomerItemStyle" TargetType="{x:Type ListViewItem}">
<!-- Stretch the content of each cell so that we can
right-align text in the Total Sales column. -->
<Setter Property="HorizontalContentAlignment" Value="Stretch" />
<!--
Bind the IsSelected property of a ListViewItem to the
IsSelected property of a CustomerViewModel object.
-->
<Setter Property="IsSelected" Value="{Binding Path=IsSelected,
Mode=TwoWay}" />
</Style>

当CustomerViewModel对象被选中还是未选中,会引起所有选中客户销售总额发生改变。AllCustomersViewModel负责维护总销售额,以便ListView下部的ContentPresenter显示正确的数字。图17显示AllCustomersViewModel如何监控被选中或未选中的每个客户,并通知View更新要显示的值。

图17 监控选中或未选中的客户

// In AllCustomersViewModel.cs public double TotalSelectedSales { get { returnthis.AllCustomers.Sum( custVM => custVM.IsSelected ? custVM.TotalSales : 0.0); } } voidOnCustomerViewModelPropertyChanged(object sender, PropertyChangedEventArgs e) { string IsSelected = "IsSelected"// Make sure that the property name we're // referencing is valid. This is a debugging // technique, and does not execute in a Release build. (sender asCustomerViewModel).VerifyPropertyName(IsSelected); // When a customer is selected or unselected, we must let the // world know that the TotalSelectedSales property has changed, // so that it will be queried again for a new value. if (e.PropertyName == IsSelected)this.OnPropertyChanged("TotalSelectedSales"); }

UI绑定了TotalSelectedSales属性,并把该值置为货币格式。ViewModel对象,而不是View,通过返回TotalSelectedSales属性Double类型值的字符串形式,设置其货币格式。.NET Framework 3.5 SP1 为ContentPresenter增加了ContentStringFormat属性,如果你使用更老版本的WPF,你需要在代码中设置货币格式。

<!-- In AllCustomersView.xaml -->
<StackPanel Orientation="Horizontal">
<TextBlock Text="Total selected sales: " />
<ContentPresenter
Content="{Binding Path=TotalSelectedSales}"
ContentStringFormat="c"
/>
</StackPanel>

Wrapping Up 总结

WPF为应用程序开发者提供了很多,学习利用WPF赋予的力量,但需要转变思维模式。MVVM模式是设计和开发WPF程序的一种简单而又有效的一套指导方针。它允许你创建数据、行为和展示强分离的程序,这更容易控制软件开发中的混乱因素。

 

2012-04-06 14:46 冰品羽扇

MVVM有很多优点,但缺点也相对蛋生,稍复杂的界面还要运行时和设计时,要虚拟一堆数据供设计时来用,不然UI都看不到,每当我看到d:DataContext="{d:DesignInstance IsDesignTimeCreatable=True, Type=Design:FUCKViewModel}" 这种东西就很不爽很不爽!
2012-04-06 16:54  sundayle
设计界面时候可以用SampleData
用MVVM模式开发的本来目的就是把界面开发和逻辑完全分离, 你只需要把你的DataContext 指向你的SampleData就可以了。用Blend很方便。

2012-04-06 17:09  sundayle
@顾思行
3年前刚开始用WPF做项目的时候还不知道有啥框架也没有blend 感觉很不方便。后来知道了blend,朋友介绍了个叫nRoute的mvvm框架,觉得开发起来很舒服。 所以一直到现在一直用nRoute. 不过前段时间因为nRoute支持wp7不是很好。 所以最近正在学mvvm light. :)

[ 楼主2012-04-06 17:12  顾思行
@sundayle
嗯,一起学习,MVVM Light最具特色的估计就是其消息机制了。以后多多交流.:)

  2012-04-07 07:17  孙长宇
谢谢楼主的辛勤翻译,这类文章对加深理解有很大的帮助。

我在过去的一年里始终从事MVVM实践的工作,在实践和应用的过程中,事实上并没有从View去抽象ViewModel,而是面向业务而设计的ViewModel,这样的目的是为了保证ViewModel的可复用性(如果ViewModel是面向View的,那么在另一个View中,它的可复用性基本上是零),或许叫它DomainModel比较合适一些。这样的实践我们也取得了一些成果,已经私信发你我的联系方式,望有幸能和楼主沟通。

BTW:个人认为,事实上,支撑起这样完美的用户界面/代码逻辑分离设计的,还有Trigger/Action/Behavior等。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值