返回总目录 本篇目录 事件总线 定义事件 触发事件 处理事件 句柄注册 取消注册 在C#中,我们可以在一个类中定义自己的事件,而其他的类可以注册该事件,当某些事情发生时,可以通知到该类.这对于桌面应用或者独立的windows服务来说是非常有用的.但对于一个web应用来说是有点问题的,因为对象都是在web请求中创建的,而且这些对象生命周期都很短,因而注册某些类的事件是很困难的.此外,注册其他类的事件会使得类紧耦合. 领域事件用于解耦并重复利用应用中的逻辑. 事件总线 事件总线是被所有触发并处理事件

前面已经对Castle Windsor的基本使用进行了学习,有了这个基础,接下来我们将把我们的事件总线再次向ABP中定义的事件总线靠近.从源码中可以知道在ABP中定义了Dictionary,存放三种类型的Factory,然后通过容器的方式实例化相应的handlerfactory.承接前面的随笔,我们为什么要使用IOC? IOC是用来代替反射的.那么反射在我们EventBus中有什么功能?反射是用来创建handler的实例的.那么我们的容器其实就是用来初始化实例这么一点功能的,所以我们不需要过多的

在上一篇的随笔中,我们已经初步完成了EventBus,但是EventBus中还有诸多的问题存在,那么到底有什么问题呢,接下来我们需要看一看ABP中的源码是如何定义EventBus的. 1.第一个点 在ABP中提供了对Action类型的支持,而我们的自己定义的类中只是针对继承了IEventHandler的接口的类 2.第二个点 在ABP中使用了线程安全的ConcurrentDictionary来存放映射关系,因为EventBus作为一个单例存在,这是必须要考虑的.ConcurrentDiction

承接上一篇时间总线的学习,在上一篇中我们实现了取消显式注册事件的方式,采用使用反射的方式.这样的好处可以解除Publisher和Scriber的显式依赖,但是问题又来了,因为我们只有Publisher和Scriber,而且我们又要实现这两者的通信,那么无论使用那种方式都不可能解除两者的依赖关系,反射也只是将依赖关系进行隐藏罢了.而且还有一个至关重要的问题,那个我们每个Publisher都得去写那么一坨的反射代码,而且这些代码其实都是公用的.写到这里,突然感觉要解决这两个问题,有一种想法呼之欲出,

什么是事件总线呢?官方的文档说,它是一个单例对象,由其他的类共同拥有,可以用来触发和处理事件.这个东西确实比较陌生,为什么要使用事件总线,或者说事件总线的优势是什么???首先我们可以明确的是,事件总线的出现是用来代替我们传统的事件的,那么我们传统的事件到底有什么不好呢??我们由浅入深,慢慢研究. 事件我们都比较熟悉,我们用两个例子回顾一下. 1.第一个例子,以前我们在winform的开发程序中到处都是事件,比如 sender:触发事件的对象 e:事件的数据,传递参数 方法中的内容:事件的处理逻辑

http://www.aspnetboilerplate.com/Pages/Documents/EventBus-Domain-Events EventBus EventBus是个单例,获得EventBus的引用可有下面两个方法: 默认的EventBus实例,使用EventBus.Default即可找到它. EventBus.Default.Trigger(...); //trigger an event 为单元测试考虑,更好的做法是通过依赖注入,获得EventBus的引用,下面是通过属性注入

在上一篇文章中,我们复习了一下事件的经典的发布订阅模式,同时对是事件源和时间处理逻辑进行抽象统一,用起来也没有问题.但是还是有很多的问题,比如说我们Handle方法其实是违背了单一性的原则的,里面混杂了各个EventData的处理逻辑,这个方法将会越来越大,越来越慢,看着越来越难受.好,那么先解决今天的第一个问题.既然我们前面为了单一化原则,分别定义了不同的xxEventData,那么我们可以同样的定义不同的xxEventHandler. 创建不同的Handler public class Fi

0.简介 事件总线就是订阅/发布模式的一种实现,本质上事件总线的存在是为了降低耦合而存在的. 从上图可以看到事件由发布者发布到事件总线处理器当中,然后经由事件总线处理器调用订阅者的处理方法,而发布者和订阅者之间并没有耦合关系. 像 Windows 本身的设计也是基于事件驱动,当用户点击了某个按钮,那么就会触发相应的按钮点击事件,而程序只需要监听这个按钮点击事件即可进行相应的处理,而事件被触发的时候往往都会附带相应的事件源,事件所产生的数据等. 还是以按钮被点击为例,该事件被触发的时候会装填上触发

一.简要介绍 ABP vNext 封装了两种事件总线结构,第一种是 ABP vNext 自己实现的本地事件总线,这种事件总线无法跨项目发布和订阅.第二种则是分布式事件总线,ABP vNext 自己封装了一个抽象层进行定义,并使用 RabbitMQ 编写了一个基本实现. 在使用方式上,两种事件总线的作用基本相同. 事件总线分布在两个模块,在 Volo.Abp.EventBus 模块内部,定义了事件总线的抽象接口,以及本地事件总线 (ILocalEventBus) 的实现.分布式事件总线的具体实现,

前言 上一节咱们讲了LocalEventBus,本节来讲本地事件总线(DistributedEventBus),采用的RabbitMQ进行实现. Volo.Abp.EventBus.RabbitMQ模块内部代码并不多,RabbitMQ的操作都集中在Volo.Abp.RabbitMQ这个包中. 正文 我们从模块定义开始看,项目启动的时候分别读取了appsetting.json的配置参数和调用了RabbitMqDistributedEventBus的Initialize函数. public clas

[https://docs.abp.io/zh-Hans/abp/latest/Distributed-Event-Bus-RabbitMQ-Integration](ABP vNext官方文档链接),基本使用可直接阅读官方文档,云怀不重复造轮子,只做官方未提到但重要的说明 关键配置说明 关键配置类:AbpRabbitMqEventBusOptions.cs 用于配置连接名.队列名即要监听的队列名.交换机名; 关键配置类:AbpRabbitMqOptions 即原始RabbitMq针对.NET的

领域事件(事件总线) 事件总线 注入IEventBus 获取默认实例 定义事件 预定义事件 处理异常 实体更改 触发事件 处理事件 处理基础事件 处理者异常 处理多个事件 注册处理者 自动 手动 取消注册 在C#中,一个类可以定义自己的事件,其他类可以注册它以便当一些事情发生时就会被通知.对于桌面应用或者单独的windows服务而言,这是非常有用的.但是,对于Web应用,会有一点儿问题,因为对象在web请求中被创建并且是短暂存在的.注册类事件非常困难.直接注册另一个类的事件会使类变得紧耦合. 在

事件总线就是订阅/发布模式的一种实现    事件总线就是为了降低耦合 1.比如在winform中  到处都是事件 触发事件的对象  sender 事件的数据    e 事件的处理逻辑  方法体 通过EventBus实现事件对象和处理逻辑的解耦 1.抽离事件对象    发生时间的事件   触发事件的对象源(可选) // // 摘要: // Defines interface for all Event data classes. public interface IEventData { // /

浅入 ABP 系列(4):事件总线 版权护体作者:痴者工良,微信公众号转载文章需要 <NCC开源社区>同意. 目录 浅入 ABP 系列(4):事件总线 事件总线 关于事件总线 为什么需要这个东西 事件总线创建过程 订阅事件 事件 发布事件 全局异常加入事件总线功能 创建事件 订阅事件 发布事件 测试 记录事件 这一篇将来学习 ABP 中的事件总线,然后结合在我们的基架项目中,逐渐构建一个完整的系统. 源码地址:https://github.com/whuanle/AbpBaseStruct 事

译注: ABP的主要负责人hikalkan最近又发布了一篇博客, 说明了ABP vNext的微服务演示,项目状态和路线图.其中特意对ABP的中文社区进行了感谢! 本文翻译自该博客文章(https://abp.io/blog/abp/Microservice-Demo-Projects-Status-and-Road-Map). 微服务演示,项目状态和路线图 在ABP vNext上的第一个公告之后,我们对代码库进行了很多改进(GitHub存储库上的1100多次提交).我们已经创建了功能,示例,文档

译者注 ASP.NET Boilerplate是.Net平台非常优秀的一个开源Web应用程序框架,在国内也有大量的粉丝. 近日, 本人在github上闲逛, 发现ASP.NET Boilerplate团队又悄悄的建立了一个新项目: ABP vNext 从名称可以看出来, 这是ASP.NET Boilerplate的下一代框架. 那么, 为什么要开发这个新框架? 之前的框架还会继续维护吗? ASP.NET Boilerplate团队的领导者hikalkan前几天发布了一篇博客(使用的就是ABP v

一.简要说明 文章信息: 基于的 ABP vNext 版本:1.0.0 创作日期:2019 年 10 月 24 日晚 更新日期:暂无 ABP vNext 提供了后台工作者和后台作业的支持,基本实现与原来的 ABP 框架类似,并且 ABP vNext 还提供了对 HangFire 和 RabbitMQ 的后台作业集成.开发人员在使用这些第三方库的时候,基本就是开箱即用,不需要做其他复杂的配置. 后台作业在系统开发的过程当中,是比较常用的功能.因为总是有一些长耗时的任务,而这些任务我们不是立即响应的

一.简要介绍 ABP vNext 框架本身就是围绕着 DDD 理念进行设计的,所以在 DDD 里面我们能够见到的实体.仓储.值对象.领域服务,ABP vNext 框架都为我们进行了实现,这些基础设施都存放在 Volo.Abp.Ddd.Domain 项目当中. 本篇文章将会侧重于理论讲解,但也只是一个抛砖引玉的作用,关于 DDD 相关的知识可以阅读 Eric Evans 所编写的 <领域驱动设计:软件核心复杂性应对之道>. PS: 该书也是目前我正在阅读的 DDD 理论书籍,因为基于 DDD 理

一.简要介绍# ABP vNext 是 ABP 框架作者所发起的新项目,截止目前 (2019 年 8 月 20 日) 已经拥有 1400 多个 Star,最新版本号为 v 0.19.0,可以尝试用于生产环境.新的 ABP vNext 框架完全是基于 ASP .NET Core 进行开发,其完全模块化的组件库能够让开发人员拥有更多的选择空间. ABP vNext 框架核心库比 ABP 框架更加精简,因为将原有许多的组件从其核心库抽离成独立的组件.这样开发人员可以更加灵活的选择自己需要的功能进行集成

一.简要介绍 在以前的文章里面,我们介绍了 ABP vNext 在 DDD 模块定义了仓储的接口定义和基本实现.本章将会介绍,ABP vNext 是如何将 EntityFramework Core 框架跟仓储进行深度集成. ABP vNext 在集成 EF Core 的时候,不只是简单地实现了仓储模式,除开仓储以外,还提供了一系列的基础设施,如领域事件的发布,数据过滤器的实现. 二.源码分析 EntityFrameworkCore 相关的模块基本就下面几个,除了第一个是核心 EntityFram