解析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

相关文章

python常见环境管理工具超全解析

《python常见环境管理工具超全解析》在Python开发中,管理多个项目及其依赖项通常是一个挑战,下面:本文主要介绍python常见环境管理工具的相关资料,文中通过代码介绍的非常详细,需要的朋友... 目录1. conda2. pip3. uvuv 工具自动创建和管理环境的特点4. setup.py5.

全面解析HTML5中Checkbox标签

《全面解析HTML5中Checkbox标签》Checkbox是HTML5中非常重要的表单元素之一,通过合理使用其属性和样式自定义方法,可以为用户提供丰富多样的交互体验,这篇文章给大家介绍HTML5中C... 在html5中,Checkbox(复选框)是一种常用的表单元素,允许用户在一组选项中选择多个项目。本

Python包管理工具核心指令uvx举例详细解析

《Python包管理工具核心指令uvx举例详细解析》:本文主要介绍Python包管理工具核心指令uvx的相关资料,uvx是uv工具链中用于临时运行Python命令行工具的高效执行器,依托Rust实... 目录一、uvx 的定位与核心功能二、uvx 的典型应用场景三、uvx 与传统工具对比四、uvx 的技术实

SpringBoot排查和解决JSON解析错误(400 Bad Request)的方法

《SpringBoot排查和解决JSON解析错误(400BadRequest)的方法》在开发SpringBootRESTfulAPI时,客户端与服务端的数据交互通常使用JSON格式,然而,JSON... 目录问题背景1. 问题描述2. 错误分析解决方案1. 手动重新输入jsON2. 使用工具清理JSON3.

Redis过期删除机制与内存淘汰策略的解析指南

《Redis过期删除机制与内存淘汰策略的解析指南》在使用Redis构建缓存系统时,很多开发者只设置了EXPIRE但却忽略了背后Redis的过期删除机制与内存淘汰策略,下面小编就来和大家详细介绍一下... 目录1、简述2、Redis http://www.chinasem.cn的过期删除策略(Key Expir

Go学习记录之runtime包深入解析

《Go学习记录之runtime包深入解析》Go语言runtime包管理运行时环境,涵盖goroutine调度、内存分配、垃圾回收、类型信息等核心功能,:本文主要介绍Go学习记录之runtime包的... 目录前言:一、runtime包内容学习1、作用:① Goroutine和并发控制:② 垃圾回收:③ 栈和

Spring组件实例化扩展点之InstantiationAwareBeanPostProcessor使用场景解析

《Spring组件实例化扩展点之InstantiationAwareBeanPostProcessor使用场景解析》InstantiationAwareBeanPostProcessor是Spring... 目录一、什么是InstantiationAwareBeanPostProcessor?二、核心方法解

深入解析 Java Future 类及代码示例

《深入解析JavaFuture类及代码示例》JavaFuture是java.util.concurrent包中用于表示异步计算结果的核心接口,下面给大家介绍JavaFuture类及实例代码,感兴... 目录一、Future 类概述二、核心工作机制代码示例执行流程2. 状态机模型3. 核心方法解析行为总结:三

springboot项目中使用JOSN解析库的方法

《springboot项目中使用JOSN解析库的方法》JSON,全程是JavaScriptObjectNotation,是一种轻量级的数据交换格式,本文给大家介绍springboot项目中使用JOSN... 目录一、jsON解析简介二、Spring Boot项目中使用JSON解析1、pom.XML文件引入依

Python中文件读取操作漏洞深度解析与防护指南

《Python中文件读取操作漏洞深度解析与防护指南》在Web应用开发中,文件操作是最基础也最危险的功能之一,这篇文章将全面剖析Python环境中常见的文件读取漏洞类型,成因及防护方案,感兴趣的小伙伴可... 目录引言一、静态资源处理中的路径穿越漏洞1.1 典型漏洞场景1.2 os.path.join()的陷