Composite Application Guidance for WPF(8)——事件

Prism的事件并没有直接使用C#的Event或WPF的RoutedEvent, 而是CompositeWpfEvent, 今天简单地谈一谈

1, 为什么是全新打造的CompositeWpfEvent,而非C#的Event或WPF的RoutedEvent?

原因一个: 断开事件发布者和事件订阅者之间的耦合.比如说模块A要订阅模块B的某一个时间,而模块A没有对模块B进行直接引用而是通用依赖注入等方式进行沟通的,所以在编译时无法进行事件的订阅.

而对事件的发布和注册则是通过EventAggregator来统一管理的,其是订阅者和订阅者之间的桥梁,关于EventAggregator,稍后会谈到

不过值得一提的是,CompositeWpfEvent更多地专注在模块之间的事件沟通,他并不是用来取代c#的Event和WPF的RoutedEvent的,他们在处于不同的层面上.

2, EventAggregator

Prism采用了一个称为EventAggregator的聚合器来统一管理事件(CompositeWpfEvent).

这实际上也是一种较常用的模式, 其思想比较简单,提供所有事件的实例:

  /// <summary>
  /// 定义一个接口,其用于获取事件类型的实例
  /// </summary>
  public interface IEventAggregator
  {
    /// <summary>
    /// 获取事件类型的一个实例
    /// </summary>
    /// <typeparam name="TEventType">要获取实例的事件类型</typeparam>
    /// <returns>事件类型<typeparamref name="TEventType"/>的一个实例.</returns>
    [System.Diagnostics.CodeAnalysis.SuppressMessage("Microsoft.Design", "CA1004:GenericMethodsShouldProvideTypeParameter")]
    TEventType GetEvent<TEventType>() where TEventType : EventBase;
  }

所有的事件发布者和订阅者都从EventAggregator从去获取事件来进行发布和订阅, 发布者不关心订阅者是谁,

订阅者也不关心发布者时谁,同一事件可以有着不同的发布者,同一事件也可以有多个订阅者,这形成了多对多的关系.

但可能有人会问, 当我需要指定事件的发布者是谁时该怎么办呢, 就像普通事件中的Sender参数?

很简单, 事件可以传递任意类型的TPlayload参数(相当于XXXEventArgs)

关于EventAggregator模式,你可以参考这里http://martinfowler.com/eaaDev/EventAggregator.html

在Prism中,EventAggregator作为一个基础服务添加到一容器中

以上是小编为您精心准备的的内容,在的博客、问答、公众号、人物、课程等栏目也有的相关内容,欢迎继续使用右上角搜索按钮进行搜索实例
, 模块
, 事件
, 实例wpf
, RoutedEvent
, 一个
, 订阅事件
, 订阅者
发布者
guidance for、wpf application、wpf application类、wpfapplication1、wpf application介绍,以便于您获取更多的相关知识。

时间: 2024-11-02 01:31:57

Composite Application Guidance for WPF(8)——事件的相关文章

Composite Application Guidance for WPF(4)——Bootstrapper

在默认情况下,WPF程序的启动方式APP的XAML中指定StartUri,然后IDE会自动帮我们生成一个Main方法,然后将StartUri中指定的窗口New一个出来,并作为应用程序的主窗口,但我们在Composite Application Guidance for WPF(3)--创建第一个Composite WPF Application(如果你不了解Prism的启动方式,那么建议你阅读) 中改变了这种方式: public App() { var boot = new Bootstrapp

Composite Application Guidance for WPF(1)--概览

什么是Composite Application Guidance for WPF(以下简称Prism) 我们想象一下,在复杂的企业级开发中,我们的开发规模非常的大,以至于我们需要将其分解成多个小的模块,以便分发给不同的人,甚至是在不同地方的团队分别进行开发和测试,最后我们在将这些相对独立的模块集成起来形成一个完整的应用.所以我们需要找到一种方法来帮助我们划分和组织这些模块,以使他们相对独立(低耦合),当然,我们也需要找到一种较好的方式让模块之间进行通讯. 这个问题最早被CAB所关注(如果你不了

Composite Application Guidance for WPF(2)

Composite Application Library(CAL) 1,一个Composite Application 的基本组成 Composite Application Library(CAL)作为Composite Application Guidance的最重要的组成部分,为我们提供打造Composite Application的最基础的组件和服务. 看看下面这张图 一个Composite Application通常由这些部分组成的(与此同时,CAL相应的为我们提供了这些基础组件)

Composite Application Guidance for WPF(7)——模块

既然是Composite Application ,毫无疑问地将涉及到"模块(Module)"以及"模块化(Modularity)",今天简单地谈谈Prism中的模块,这包括:模块化,如何在Prism中枚举和加载模块等等 1,模块化 事实上"模块化"这个标题足以让我心惊胆战而无法完成此篇随笔,因为其是一个非常大的话题,并且在生活中随处可见,如果你对此感兴趣的话,不妨阅读一下<设计规则:模块化的力量>这本书.不过就比较狭隘地从软件开发这

Composite Application Guidance for WPF(3)

创建第一个Composite WPF Application 1.前提条件: 你需要下载到CAL(Composite application library)库,实际上就是几个DLL文件,在项目中将会引用到他们来打造我们的程序,你可以从这里下载到它们.当然你也需要一个能打造WPF应用的IDE,比如VS2008. 2.创建Shell Project 2.1.在VS中新建一个WPF Application,将CAL库文件添加到项目引用中 2.2.将自动生成的Window1主窗口及其相应的文件重命名为

Composite Application Guidance for WPF(5)——依赖注入容器

依赖注入容器和Prism的基础服务已经在本系列随笔中提到过很多次,今天将其分离出来专门说一说 1, 为什么要使用依赖注入容器 我们知道, 在Composite Application中各个模块之间是松耦合的关系, 也就是在设计的时候尽可能地减少模块间的依赖, 但无论如何从业务角度讲, 他们之间总还是要相互通信与合作的. 所以依赖注入容器在这其中扮演了一个桥梁般的角色. 比如当创建某一个组件实例的时候, 其依赖于另外的一个组件或服务, 此时依赖注入容器会将其需要的信息"注入(Injection)&

Composite Application Guidance for WPF(9)——命令

这里的"命令"即Command模式中的"Command",几乎每个应用程序都有该模式的运用,如何"复制""粘贴""撤销"等操作.我们知道,该模式将操作的请求者和操作的执行逻辑隔离开来,并且其对请求排队以及撤销重复等操作有着良好的支持,所以被广泛应用.而WPF将其做了进一步的封装和改进,使得WPF程序能够很容易地使用命令和打造自定义命令,另外,WPF内置的数十种常用命令以及先进的命令路由模式(Routed)使

Composite Application Guidance for WPF(6)——服务

在Ioc和DI中,最熟悉的一个词语便是服务(Service)了,关于Service的定义以及其与Component(组件)的一些小小区别,请参考Martin Fowler的这篇文章,我们这里主要看看在Prism中是如何实现服务的注册和使用的. 1,Service Locator (服务定位器) 这是必须首先讨论的问题,当我们的一个类型对象要依赖另外一个服务方可生存的时候,我们应该如何引用这个服务呢? 最简单的方式是如下的直接引用: 我们可以看到ClassA直接引用了其依赖的两个服务Service

wpf c#-WPF键盘事件获取区分大小写的字符

问题描述 WPF键盘事件获取区分大小写的字符 如何在WPF的keyup事件中获取键盘的字符,需要区分大小写