MVVM模式用依赖注入的方式配置ViewModel并注册消息

最初的想法

这次主要讨论下给View指定ViewModel的事情。一般来说给View指定ViewModel常用的方式有两种,一种是在View的后台代码中写DataContext = new ViewModel(),还有一种是在XAML中指定View的DataContext。这两种方式都使得View对ViewModel产生了依赖,这种情况下可以考虑用依赖注入的方式使取消View对ViewModel的直接依赖。依赖注入一般来说可以通过构造函数注入、通过设置属性注入,这两种方法对于View来说都不合适。因此可以使用IoC Container,让View主动去获取对应的ViewModel。

其实给View指定一个ViewModel并不属于频繁的操作,而且改起来也很容易,费半天劲搞个依赖注入确实不太至于。就像上篇文章中废了半天劲搞了个View和ViewModel的通信一样,用到的概率比较小,而且也有别的方式解决,虽然那种方式并不符合MVVM模式。不过View除了依赖ViewModel之外对消息注册器也是会产生依赖的,而且某种类型的View一般来说都依赖固定类型的ViewModel和消息注册器,因此可以一次注入两个依赖,这样貌似就值了,至少我认为是值了,所以有了ViewModelManager这个类。

ViewModel和MessageManager的依赖注入

使用静态类ViewModelManager来当作IoC Container。往IoC Container里注册依赖关系一般有两种方式,一种是将依赖关系以某种形式(例如xml)保存在外部,一种是在程序中注册到一个列表里。我采取第二种做法,因为比较容易:)

程序在启动时使用ViewModelManager.Register将依赖关系注册到ViewModelManager中,View在构造函数中调用ViewModelManager.SetViewModel(this);来设置View的DataContext并通过依赖的消息注册器注册消息,消息注册器可以为空,代表View不接收消息。它们的关系如图所示:

需要说明的有两个地方:

一个是View和ViewModel的对应关系。一般来说一个View对应着一种ViewModel,这样注册起来是没问题的。但这个并不绝对,理论上来说一个View可以将DataContext设置为任意ViewModel,如果一个View可以设置多种ViewModel该如何处理呢,这时候可以在ViewModelManager注册时添加Token属性,然后用SetViewModel(this,token)的方式指定特定的ViewModel为DataContext。

另一个是消息注册的范围。因为一般来说ViewModel都是和绑定的View通信。所以默认情况下,消息注册到单独一个MessageManager中,这个MessageManager保存ViewModel中,ViewModel使用这个MessageManager发送消息,发送的消息由View接收。但如果需要和其他View通信,需要把消息注册到MessageManager.Default中,这个对象是static的,要达到这个目的只要在View设置ViewMode时这样来SetViewModel(this,isGlobalMsg:true)即可。如果ViewModel又想和绑定的View单独通信,有时候还需要和别的View通信,可以在消息注册器中注册时将需要单独通信的消息设置一个Group,ViewModel在发送消息时加一个Group过滤一下即可。一个Group可以理解为消息的单独一个通道。

顺带一提,好吧只是顺带一提的是,在给View注入ViewModel时,顺便把ViewModel的UIDispatcher属性设置为了View的Dispatcher,虽然我不知道这有什么用。但这样在ViewModel中使用UIDispatcher时即为相关的View的Dispatcher。如果要使用MainWindow的Dispatcher可以通过DispatcherHelper.Dispatcher或者App.Current.MainWindow.Dispatcher获得。

写在最后

到此为止我能想到的MVVM框架的功能算是基本实现了,遇到的需求十分有限,才能也十分有限,能想到的就这几个了,欢迎回复讨论,也欢迎加我QQ16141860交流。之前一直是在TestArea这个仓库里进行测试,现在这个小框架整理了下,放到AyxMVVM仓库里了。现在有些想法还不太成熟,使用过程中遇到问题也会随时修正,以后就都修改到AyxMVVM中了,TestArea中的MyMVVM不再维护了。另外给仓库起名真是件麻烦事,干脆统一都用Ayx+XXX的方式,这样既容易重复的概率又十分小。Ayx是我名字拼音的首字母,想想看以拼音A开头的姓氏之少就能想到几乎不会出现重复了。最后,10月6日看了微软的秋季产品发布会后信仰充值成功。对UWP十分感兴趣,下一步打算学习一下。

原文地址:https://www.cnblogs.com/wlming/p/8309352.html

时间: 2024-08-02 18:29:50

MVVM模式用依赖注入的方式配置ViewModel并注册消息的相关文章

spring 配置bean的方法及依赖注入发方式

Bean 的配置方式:通过全类名(反射).通过工厂方法(静态工厂方法 & 实例工厂方法).FactoryBean 这里依据全类名配置bean <bean id="helloWord" class="com.spring.HelloWord"> <property name="userName" value="springsss"></property> </bean> 依

6.在MVC中使用泛型仓储模式和依赖注入实现增删查改

原文链接:http://www.c-sharpcorner.com/UploadFile/3d39b4/crud-operations-using-the-generic-repository-pattern-and-dep/ 系列目录: Relationship in Entity Framework Using Code First Approach With Fluent API[[使用EF Code-First方式和Fluent API来探讨EF中的关系]] Code First Mig

依赖注入及AOP简述(五)——依赖注入的方式 .

二.依赖注入的应用模式 前面我们了解了依赖注入的基本概念,也对一些依赖注入框架进行了简单的介绍,这一章我们主要来讨论作为开发者如何利用依赖注入框架来实现依赖注入的设计思想. 1.     依赖注入的方式 前面我们提到,所谓“依赖”,最简单地去解释就是一个Java类里的成员变量.我们都知道,给一个类中的私有成员变量赋值的方法通常有:通过Constructor构造方法.通过Setter方法.通过反射机制将私有变量的可见性设为true这三种方法.同样道理,依赖注入框架也是利用这三种方式来完成依赖对象的

Spring 依赖注入的方式

Spring 支持3中依赖注入的方式 1.属性注入  通过setter 方法注入Bean的属性或依赖的对象. <bean id = " " class = " "> <property name = " " value = " "> </property>     <property name = " " value = " "> <

WebApi学习笔记06:使用webapi模板--仓储模式--Unity依赖注入

1.Web项目 1.1概述 对数据操作封装使用存储模式是很常见的方式,而使用依赖注入来降低耦合度(方便创建对象,可以抛弃经典的工厂模式)…… 1.2创建项目 1.3添加模型 在Models下,添加Product.cs: namespace WebApi06.Models { public class Product { public int ID { get; set; } public string Name { get; set; } public decimal Price { get;

分层,工厂模式,依赖注入控制反转

1.分层:就如同一个人自己制造一个锤子,自己动手丰衣足食.你需要他就自己new一个该实例.无法实现二者之间的松耦合 2.工厂模式:一个人需要一个锤子,他找工厂,工厂帮他造了一个锤子.工厂给你制造的锤子,但是如何造的你不需要知道.你直接调用该接口就可以了,具体你不需要知道.调用者无须关心被调用者具体实现过程,只需要找到符合某种标准(接口)的实例,即可使用 3.依赖注入:一个人需要一个锤子,他打电话给卖锤子的叫他送货上门.你喜欢哪家的锤子,直接叫哪家送货上门就OK.用者无须自己定位工厂,程序运行到需

EntityFramework Core依赖注入上下文方式不同造成内存泄漏了解一下?

前言 这个问题从未遇见过,是一位前辈问我EF Core内存泄漏问题时我才去深入探讨这个问题,刚开始我比较惊讶,居然还有这种问题,然后就有了本文,直接拿前辈的示例代码并稍加修改成就了此文,希望对在自学EF Core过程中的童鞋能有些许帮助. EntityFramework Core内存泄漏回顾 接下来我将用简单示例代码来还原整个造成EntityFramework Core内存泄漏的过程,同时在这个过程中您也可思考一下其中的原因和最终的结果是否一致. public class TestA { pub

spring依赖注入的方式(一)

为了方便类的管理,spring提供了依赖注入的思想:类的实例化不由程序员控制,而是交给sprig容器进行管理. spring提供了多种类型的注入方式---注解.xml注入: 1  注解注入 有两种:@Autowired @Resource.两种都可以实现注入,但是二者的差别也很明显. @Resource 默认按照名称注入,在找不到名称的时候,会继续通过类型匹配: @Autowired 默认按照类型注入: @Resource 注解是由J2EE提供,而@Autowired是由spring提供,故为了

Spring依赖注入的简化配置

一, 很久很久以前, 当我们不用@Autowire注解时, 依赖注入要么通过setter方法, 要么通过构造方法; 需要在配置文件里配置一大堆property-ref.......... 二, 若使用注解, 则造成代码的侵入性较强, 后期改起来也很蛋疼; 三, 怎么办? ----->  用default-autowire!! 废话不多说, 直接上代码: 1, 配置文件: 1 <beans xmlns="http://www.springframework.org/schema/bea