解析Caliburn.Micro(三)

2023-10-28 05:58
文章标签 解析 micro caliburn

本文主要是介绍解析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,它的方法如下:

   1: public static Func<object, DependencyObject, object, UIElement> LocateForModel
   2: 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的接口定义如下:

   1: public interface IViewAware
   2: {
   3:     void AttachView(object view, object context = null);
   4:     object GetView(object context = null);
   5:     event EventHandler<ViewAttachedEventArgs> ViewAttached;
   6: }

  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中,我们使用类似

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

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

Property Convention

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

 

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

这篇关于解析Caliburn.Micro(三)的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/291157

相关文章

Qt实现网络数据解析的方法总结

《Qt实现网络数据解析的方法总结》在Qt中解析网络数据通常涉及接收原始字节流,并将其转换为有意义的应用层数据,这篇文章为大家介绍了详细步骤和示例,感兴趣的小伙伴可以了解下... 目录1. 网络数据接收2. 缓冲区管理(处理粘包/拆包)3. 常见数据格式解析3.1 jsON解析3.2 XML解析3.3 自定义

Golang HashMap实现原理解析

《GolangHashMap实现原理解析》HashMap是一种基于哈希表实现的键值对存储结构,它通过哈希函数将键映射到数组的索引位置,支持高效的插入、查找和删除操作,:本文主要介绍GolangH... 目录HashMap是一种基于哈希表实现的键值对存储结构,它通过哈希函数将键映射到数组的索引位置,支持

Python使用getopt处理命令行参数示例解析(最佳实践)

《Python使用getopt处理命令行参数示例解析(最佳实践)》getopt模块是Python标准库中一个简单但强大的命令行参数处理工具,它特别适合那些需要快速实现基本命令行参数解析的场景,或者需要... 目录为什么需要处理命令行参数?getopt模块基础实际应用示例与其他参数处理方式的比较常见问http

Python利用ElementTree实现快速解析XML文件

《Python利用ElementTree实现快速解析XML文件》ElementTree是Python标准库的一部分,而且是Python标准库中用于解析和操作XML数据的模块,下面小编就来和大家详细讲讲... 目录一、XML文件解析到底有多重要二、ElementTree快速入门1. 加载XML的两种方式2.

Java的栈与队列实现代码解析

《Java的栈与队列实现代码解析》栈是常见的线性数据结构,栈的特点是以先进后出的形式,后进先出,先进后出,分为栈底和栈顶,栈应用于内存的分配,表达式求值,存储临时的数据和方法的调用等,本文给大家介绍J... 目录栈的概念(Stack)栈的实现代码队列(Queue)模拟实现队列(双链表实现)循环队列(循环数组

java解析jwt中的payload的用法

《java解析jwt中的payload的用法》:本文主要介绍java解析jwt中的payload的用法,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝赐教... 目录Java解析jwt中的payload1. 使用 jjwt 库步骤 1:添加依赖步骤 2:解析 JWT2. 使用 N

Python中__init__方法使用的深度解析

《Python中__init__方法使用的深度解析》在Python的面向对象编程(OOP)体系中,__init__方法如同建造房屋时的奠基仪式——它定义了对象诞生时的初始状态,下面我们就来深入了解下_... 目录一、__init__的基因图谱二、初始化过程的魔法时刻继承链中的初始化顺序self参数的奥秘默认

Java 正则表达式URL 匹配与源码全解析

《Java正则表达式URL匹配与源码全解析》在Web应用开发中,我们经常需要对URL进行格式验证,今天我们结合Java的Pattern和Matcher类,深入理解正则表达式在实际应用中... 目录1.正则表达式分解:2. 添加域名匹配 (2)3. 添加路径和查询参数匹配 (3) 4. 最终优化版本5.设计思

使用Java将DOCX文档解析为Markdown文档的代码实现

《使用Java将DOCX文档解析为Markdown文档的代码实现》在现代文档处理中,Markdown(MD)因其简洁的语法和良好的可读性,逐渐成为开发者、技术写作者和内容创作者的首选格式,然而,许多文... 目录引言1. 工具和库介绍2. 安装依赖库3. 使用Apache POI解析DOCX文档4. 将解析

Java字符串处理全解析(String、StringBuilder与StringBuffer)

《Java字符串处理全解析(String、StringBuilder与StringBuffer)》:本文主要介绍Java字符串处理全解析(String、StringBuilder与StringBu... 目录Java字符串处理全解析:String、StringBuilder与StringBuffer一、St