解析Caliburn.Micro（三）

　　书接前文，前篇文章简略了介绍了一下Caliburn.Micro（简称CM）的Action，这篇文章继续讨论CM的下一个Feature：Convention。

什么是Convention

　　Convention，翻译过来叫公约、协定。公约，一般指行为规范，达成共识的多方共同遵守的一个约定。在CM中，Convention主要用来做配对，匹配。这个配对，主要是指View和ViewModel之间的配对，前篇文章已经提过，CM是基于MVVM模式的，MVVM（Model-View-ViewModel）中，Model是用来保存数据的，相对来说它比较固定，View和ViewModel之间的关系有一些变化，简单的说一说。

View-First or ViewModel-First

　　MVVM中，ViewModel的作用是储存View的状态，封装Model的数据。ViewModel是PresentationModel模式发展而来的，ViewModel中并不会储存所有的View的状态，它只存储可能被修改的View的状态。WPF的出现，主要提供了两个技术，让ViewModel的出现成为了可能：

1. 数据绑定，WPF提供了数据绑定，View绑定到ViewModel，使用ViewModel作为它的DataContext。当ViewModel中存储的View状态发生改变的时候，View会自动刷新状态。
2. Command，WPF提供了ICommand，当用户操作View时，会通过Command把操作传递给ViewModel。

　　View的两大功能，显示数据和操作数据，分别被抽象出来，它的状态也被保存在ViewModel中，由于使用了数据绑定，View通过DataContext来关联ViewModel，两者之间是松耦合的，这也是MVVM模式的精彩之处。那么回到本篇文章要讨论的点上，View和ViewModel如何关联？谁来找到谁？View-First or ViewModel-First?

ViewModel-First

　　通常情况下，都会推荐大家ViewModel-First。设计时先设计好ViewModel，再通过数据模板（DataTemplate）来生成对应的View。这样做的好处是可以随时替换View，单元测试时可以Mock一个View测试。CM框架提供了ViewLocator来通过ViewModel定位对应的View，它的方法如下：

public static Func<object, DependencyObject, object, UIElement> LocateForModel
public static Func<Type, DependencyObject, object, UIElement> LocateForModelType

　　CM中大量使用了Func替换原有实现来完成多态，LocateForModel和LocateForModelType分别传入ViewModel的实例或者类型来返回对应的View，这两个名字有点不给力，我觉得换成GetCorrespondingView更直接一点。

　　那么这个根据ViewModel来找到View的实现是如何完成的呢？这个实现分两步，第一步，根据ViewModel来找到对应的View的类型（Type）；第二步，调用反射Activator.CreateInstance(Type type)来创建View。

　　为了更方便的从ViewModel中操作View，CM提供了IViewAware来允许在ViewModel中缓存（Cache）对应的View，IViewAware的接口定义如下：

public interface IViewAware
{
    void AttachView(object view, object context = null);
    object GetView(object context = null);
    event EventHandler<ViewAttachedEventArgs> ViewAttached;
}

　　ViewAware是IViewAware的默认实现类。当ViewModel和View被绑定到一起后，IViewAware的AttachView方法被调用，你可以重载OnViewAttached方法来针对View做一定处理，如注册View的事件（要小心事件的强引用）。当View被加载到VirualTree后，ViewAware的OnViewLoaded方法被调用，可以在这里遍历View的VisualTree做相应处理。

　　ViewLocator调用LocateForModel时也会首先判断ViewModel是不是实现了IViewAware并且已经缓存了View，如果是，那么不重新生成View而是直接返回缓存的View。这里就回到第一步，如何通过ViewModel来找到对应View的类型（Type）。

NameTransformer

　　CM使用NameTransformer来通过正则表达式推算出可能存在的View的类型，这个实现是这样的：

　　NameTransformer中定义了ReplacePattern（替换规则），ReplaceValue（替换值），GlobalFilterPattern（过滤规则）通过正则表达式来做推算工作。比如说把ReplacePattern设置为ViewModel$，把ReplaceValue设置为View，这条规则（Rule）的意义是把字符串以ViewModel结尾的部分替换成View。比如传入的ViewModel类型是Illusion.ViewModels.ShellViewModel，替换之后返回的类型是Illusion.ViewModels.ShellView。

　　ViewLocator默认实现了5条规则，分别是

1. 去掉最末尾的View；
2. 把末尾ViewModel替换成View；
3. 把末尾的PageViewModel替换成Page；
4. 把Illusion.ViewModels.ShellViewModel替换成Illusion.Views.ShellView（替换ViewModels –> Views，ShellViewModel –> ShellView）
5. 把Illusion.ViewModels.ShellPageViewModel替换成Illusion.Views.ShellPage（同上）

　　对实际项目来说，如果我们遵守着CM建议的命名规则，Illusion.ViewModels.ShellViewModel –>Illusion.Views.ShellView，CM会自动找到对应的View。如果我们把ViewModel和View分离，没有遵循CM建议的命名规则，那么就要我们在ViewLocator的NameTransformer中添加对应的规则来帮助ViewLocator找到对应的View类型。

　　CM通过ViewLocator查询到对应View的类型后，其实获得的是一个字符串（String），CM要通过程序集（Assembly）来获取真正的类型（Type）。CM没有遍历Appdomain中的全部程序集，而是新建了一个AssemblySource来保存查询范围的程序集。你可以重载BootStrapper中的SelectAssemblies来返回查询范围的程序集，也可以调用AssemblySource的Add、AddRange方法来加入新的Assembly。

　　比如我们使用DirectoryCatalog来监视插件，对应的View类型在插件中，那么我们需要把插件对应的Assembly加入到AssemblySource中，否则ViewLocator是无法找到对应的View的。CM在View和ViewModel匹配处的设计思路是提供了一些实现和扩展的空间，但还不是那么十分智能，需要我们根据项目加入一些定制来满足要求。

　　当然也可以不使用View和ViewModel的智能匹配，手动创建View和ViewModel，然后ViewModelBinder的Bind方法来手动把View和ViewModel绑定在一起。

View-First

　　在WP7环境中，推荐使用View-First模式，通过View来查询到对应的ViewModel，再把他们绑定到一起。这个实现原理以及匹配规则同ViewModel-First，这里就不做介绍了。

Action Convention

　　在前篇文章介绍过的Action中，我们使用类似

<Button cm:Message.Attach="[Event MouseEnter] = [Action Show('Enter')];
                           [Event MouseLeave] = [Action Show('Leave')]" />

　　就是使用了Action Convention，CM负责把Attach后面的字符串转化为对应的Action，这里的扩展空间不大，不细谈它了。

Property Convention

　　这是CM中强大的一部分，其中的细节包括ElementConvention都很有意思，那么，就下篇吧。 ^_^

 

作者：周永恒
出处：http://www.cnblogs.com/Zhouyongh

本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。