在此前的博客中，博主参考 eShopOnContainers 实现了一个基于 RabbitMQ 的事件总线(EventBus)。在这个项目中，它提供了一个持久化连接的类DefaultRabbitMQPersistentConnection，主要解决了 RabbitMQ 在连接断开后自动重连的问题，可实际上我们都
终于到这个系列的最后一篇，在前两篇博客中，我们分别了介绍了Binlog的概念和事件总线(EventBus)的实现，在完成前面这将近好几千字的铺垫以后，我们终于可以进入正题，即通过 EventBus 发布 Binlog，再通过编写对应的 EventHandler 来订阅这些 Binlog，
紧接上一篇博客中的思路，这次我们来说说事件总线(EventBus)，回首向来，关于这个话题，我们可能会联想到发布-订阅模式、观察者模式、IObservable与 IObserver、消息队列等等一系列的概念。所以，当我们尝试着去解释这个概念的
终于等到了周末，在经历了一周的忙碌后，终于可以利用空闲写篇博客。其实，博主有一点困惑，困惑于这个世界早已“堆积”起人类难以想象的“大”数据，而我们又好像执着于去“造”一个又一个“差不多”的“内容管理系统”，从前我们说互联网的精神是开放和分享
突然发觉，古人其实特别有趣，譬如有古语云：『常在河边走，哪有不湿鞋』，实在是富有生活气息的一句俗语，可古人又有言语：『光脚的不怕穿鞋的』，更是朴实无华的一句话。上周下班适逢天降大雨，我撑伞送一位同事到地铁站，结果走到半路人家来一句，“你快点
在上一篇博客里，我们为.NET Core原生 DI 扩展了基于名称的注入功能。而今天，我们要来聊一聊属性注入。关于属性注入，历来争议不断，支持派认为，构造函数注入会让构造函数变得冗余，其立意点主要在代码的可读性。而反对派则认为，属性注入会让组件间的
接触 .NET Core 有一段时间了，最大的感受无外乎无所不在的依赖注入，以及抽象化程度更高的全新框架设计。想起三年前 Peter 大神手写 IoC 容器时的惊艳，此时此刻，也许会有不一样的体会。的确，那个基于字典实现的 IoC 容器相当“简陋”，就像 .NET Core 里的依赖注入，默认(原生)都
有时候，我不禁在想，我们到底处在一个什么样的时代呢？而之所以会有这样的疑问，则是因为我们的习惯在不断地被这个时代向前推进，就像我用了两年多的魅蓝 Note6 屏幕出现了问题，扫视了一圈新手机，居然再找不出一款带实体键的手机，刘海屏、水滴屏、破孔屏、异形
相信大家都有这样一种感觉，Linq和Lambda是.NET 中一以贯之的存在，从最早的 Linq to Object 到 Linq to SQL，再到 EF/EF Core 甚至如今的.NET Core，我们可以看到Lambda表达式的身影出现地越来越频繁。虽然 Linq to Object 和 Linq to SQL，分别是以IEnumer
相信大家都有过周末被电话“吵醒”的经历，这个时候，客服同事会火急火燎地告诉你，客户反馈生产环境上某某数据“异常”，然后你花费大量时间去排查这些错误数据，发现这是客户使用某一种“骚”操作搞出来的“人祸”。可更多的时候，你不会这么顺利，因为你缺
博主曾经在「声明式 RESTful 客户端 WebApiClient 在项目中的应用」这篇博客中，介绍过.NET 平台下的“Retrofit”——WebApiClient，它是一种声明式的 RESTful 客户端，通过动态代理来生成 Http 调用过程代码，而调用方只需要定义一个接口，并使用相关“注解”对接口
Hi，各位朋友，大家好！欢迎大家关注我的博客，我的博客地址是: https://blog.yuanpei.me。今天是远程办公以来的第一个周末，虽然公司计划在远程两周后恢复正常办公，可面对着每天都有人离开的疫情，深知这一切都不会那么容易。窗外
最近给博客做了升级，从 3.x 升级到了 4.x，主要是在官网看到了关于静态页面生成效率提升的内容。众所周知，Hexo 在文章数目增加以后会越来越慢。博主大概是从 14 年年底开始使用 Hexo 这个静态博客的，截止到目前一共有 176 篇博客，其中的“慢”可想而知，中间甚至
有时候，版本更新太快并不是一件好事。虽然，两周一个迭代的“敏捷”开发依然被客户嫌弃交付缓慢，可一边是前端领域“求不要再更新了，学不动了”的声音，一边则是.NET Core从1.x到2.x再到3.x的高歌猛进。版本更新太快，带来的是API的频繁
我以为，时间是这个世界上最残忍的存在。因为，无论如何，你都无法阻止这如齿轮般互相咬合的时光机器，即使这世界上并没有所谓的“永动机”。习惯于沉默的时间之轮，你在或者不在，丝毫不影响它衡量宇宙万物的尺度。也许，是因为我们所拥有的时间太过短暂，所
