当前播放: 34 | MediatR:轻松实现命令查询职责分离模式(CQRS)
00:00 / 00:00
高清
  • 高清
1.0x
  • 2.0x
  • 1.5x
  • 1.25x
  • 1.0x
  • 0.5x
网页全屏
全屏
00:00
付费课程,可试看
课程目录
第一章:必备知识 (25讲)
01 | 课程介绍
免费
02 | 内容综述
免费
03 | .NET Core的现状、未来以及环境搭建
免费
04 | Startup:掌握ASP.NET Core的启动过程
免费
05 | 依赖注入:良好架构的起点
免费
06 | 作用域与对象释放行为:你知道IDisposable对象释放的时机和坑吗?
07 | 用Autofac增强容器能力:引入面向切面编程(AOP)的能力
08 | 配置框架:让服务无缝适应各种环境
09 | 命令行配置提供程序:最简单快捷的配置注入方法
10 | 环境变量配置提供程序:容器环境下配置注入的最佳途径
11 | 文件配置提供程序:自由选择配置的格式
12 | 配置变更监听:配置热更新能力的核心
13 | 配置绑定:使用强类型对象承载配置数据
14 | 自定义配置数据源:低成本实现定制化配置方案
15 | 选项框架:服务组件集成配置的最佳实践
16 | 选项数据热更新:让服务感知配置的变化
17 | 为选项数据添加验证:避免错误配置的应用接收用户流量
18 | 日志框架:聊聊记日志的最佳姿势
19 | 日志作用域:解决不同请求之间的日志干扰
20 | 结构化日志组件Serilog:记录对查询分析友好的日志
21 | 中间件:掌控请求处理过程的关键
22 | 异常处理中间件:区分真异常与逻辑异常
23 | 静态文件中间件:前后端分离开发合并部署骚操作
24 | 文件提供程序:让你可以将文件放在任何地方
25 | 路由与终结点:如何规划好你的Web API
第二章:微服务实战篇 (11讲)
26 | 工程结构概览:定义应用分层及依赖关系
27 | 定义Entity:区分领域模型的内在逻辑和外在行为
28 | 工作单元模式(UnitOfWork):管理好你的事务
29 | 定义仓储:使用EF Core实现仓储层
30 | 领域事件:提升业务内聚,实现模块解耦
31 | APIController:定义API的最佳实践
32 | 集成事件:解决跨微服务的最终一致性
33 | 集成事件:使用RabbitMQ来实现EventBus
34 | MediatR:轻松实现命令查询职责分离模式(CQRS)
35 | MediatR:让领域事件处理更加优雅
课程暂停更新声明
34 | MediatR:轻松实现命令查询职责分离模式(CQRS)

34 | MediatR:轻松实现命令查询职责分离模式(CQRS)

肖伟宇
校宝在线架构师、SkyWalking .NET探针贡献者、NetCorePal组件库创建者
61讲 约600分钟2877
单独订阅¥129
2人成团¥99
本节摘要
登录 后留言

精选留言(6)

  • Coder77
    为什么用来CAP还要在用MediatR呢?感觉CAP组件已经涵盖了MediatR的功能了。

    作者回复: MediatR 进程内的事件传递,适合领域事件在进程内的传递,CAP是跨进程跨应用的传递

    2020-03-06
    1
  • Geek_7c4953
    希望老师再讲讲request/response与response.Handle(request)的区别。想了半天也没想明白有什么区别。
    如果说前者request发起方不必依赖response的话,那后者用接口应该也能实现这一点啊。如果说业务变动,
    该修改Handle方法的还是修改,该修改request参数的也还是要修改。
    request/response到底有什么好处呢?

    作者回复: 这里的核心是命令发起的逻辑,完全与Handle的逻辑隔离开,没有任何依赖。我们可以为这两段逻辑分别构建单元测试

    2020-03-06
  • Geek_7c4953
    我最近一直在纠结一个问题,就是项目紧密耦合MidatR算不算紧耦合。我自己倒是照着这套架构撸了一套让领域事件和处理类不必实现INotification和I...Handler的接口。不过也是费了老大劲了,又是看源码,又是研究反射的。就是不知道这么做有没有必要。

    作者回复: 你自己实现一套跟使用MidatR本质上是一样的,MidatR没有引入其它依赖,足够轻,因此依赖它不会造成负担,有现成的经过验证的组件可以用,何乐而不为呢。

    2020-03-05
    1
  • 川杰
    老师,个人想法,如果这个框架,只能一个Command对应一个Handler,是不是太弱了?
    打个比方,订单创建成功命令发出;需要,物流模块,积分模块,等其他几个模块去同时相应;按照目前的方式,只能将这些逻辑写在一个Handler里。但真实代码中,物流,积分等往往是写在不同模块的;
    如果这个框架有这个限制,那我觉得应用场景就太窄了;

    作者回复: 你举例的这个场景是需要领域事件来驱动的,领域事件驱动物流、积分等模块的处理,也就是EventHandler

    2020-03-01
    1
  • zy
    用发送命令的方式以后就不能愉快的使用查找定义和引用了,个人还是喜欢对象引用的方法。

    作者回复: 发送命令的方式,可以更方便些单元测试,让测试代码更聚焦。
    代码的组织和依赖关系形成约定后,查找引用的诉求会相对弱一些,可以接受。

    2020-02-29
    1
  • zy
    事件表中状态为succeed记录可以删吗。业务会有影响吗

    作者回复: 建议定期归档一段时间,然后再删除。

    2020-02-29
    1
收起评论
看过的人还看
MySQL实战45讲

林晓斌  网名丁奇,前阿里资深技术专家

48讲 | 48165 人已学习

拼团 ¥79 原价 ¥99
DDD实战课

欧创新  人保高级架构师

24讲 | 6572 人已学习

拼团 ¥55 原价 ¥68
Electron开发实战

邓耀龙  美团高级前端工程师

35讲 | 1961 人已学习

拼团 ¥79 原价 ¥99
数据结构与算法之美

王争  前Google工程师

79讲 | 77048 人已学习

拼团 ¥79 原价 ¥99