基于.Net的发布订阅模式API的实现与详解(一)

第一次接触到发布订阅者模式写业务逻辑时，并不知道自己使用的开发模式就是基于发布订阅者，只知道使用这样的方式开发起来特别快，业务逻辑耦合性低，相互独立同时接口又能自动被回调。而后自己独立设计业务逻辑底层API和框架时，才逐渐上升到概念的深度，去总结，去实现了。由于本人开发.Net比较多，所以就分享一篇基于.Net平台的发布订阅模式的接口实现与原理，提供源码下载。

对知识最好的解说是从提问开始的，带着问题一步步深入，可更轻松高效率地达到理解的程度，首先：

• 什么是发布订阅者模式？
• 它可以解决哪些问题？为什么要使用它？
• 实现它的思想是什么？用了哪些知识？
• 拓展：它如何与复杂数据结构，异步编程结合？实现高质量的API与业务逻辑？

一、什么是发布订阅者模式？

用一个大家都能轻松理解的例子来说明：报纸，邮局，个人。

在以前互联网不是很发达的时候，人们了解最新的社会动态是通过报纸来的，报纸作者将内容写到报纸这个载体上，然后交给邮局，邮局处理个人对报纸的订阅情况，然后把报纸发给订阅人手里，报纸相当于发布者，邮局是发布订阅调度中心，个人是订阅者，这个模式在程序中运行也和报纸是一样的，解释结束。

二、它可以解决哪些问题？为什么要使用它？

其实这个问题可以换个问法：我为什么要抛弃之前已有的东西，耗费精力来学习它？它真的值得吗？
我喜欢举例子来说明抽象的概念，同样地，举几个栗子：

场景一：人与人之间打招呼
假如有天有缘，你和我在同一个公司里，因为我们是陌生人，所以必须得相互大概了解下才能更加深入地相处，你也许会问我：你今年多大呀？有女朋友了吗？在上海哪里住？这样的问题，OK，没问题，但是如果每天见面我们都先相互问这样的话题，是不是沟通效率就很差了？这样的场景基本不会出现在人与人之间的沟通上，但在程序中却很常见，比如：

private static void 告警灯()
{
    更新数据库();
    回调A接口();
    通知B接口();
    //以下是逻辑
    ......
}

虽然这样写没毛病，代码也规范，但是如果某天需求要求告警灯内多加一个“关掉水阀” 功能，一个项目中已经有成百上千这样的代码，那一点一点改起来是不是很要命？

场景二：餐厅用餐

有天你和女朋友一起去某大型餐厅用餐，大餐已经上桌了，你发现有的菜需要筷子，有的需要叉子，甚至有的需要很多奇奇怪怪的餐具，而这家餐厅里没有服务员，但是厨具却很齐全，你需要自己去打开橱柜，在无边无际的餐具的海洋里去挑选自己需要的餐具，好的，等餐具找好，估计菜也凉了。

这是面向过程编程普遍会出现的情况：面向对象提供了大量功能独立的接口供使用者使用，但是使用者只在乎当前他的需求，而不想浪费时间知道有哪些工具可供使用，而餐具也一样，它不想也不在乎谁去调用他。

那么用订阅发布者模式来描述这个场景：这个餐厅里有服务员，顾客不关心他用的餐具叫什么名字，叉子也不知道会被谁使用，一切都丢给服务员去处理，顾客要的时候找服务员即可，也不存在要用叉子必先用筷子来引用的问题（编程中会出现逻辑耦合的问题）。

好了就举这两个例子，其实发布订阅的好处还有很多，但是上面这两个例子出现的问题任意一个都是需要耗费大量的精力和成本去滚轮子的，在大型项目中由不可取，但是用发布订阅却能很好的解决。第一个例子暴露的是接口高可用重复率的问题， 第二个是逻辑节点多可能会涉及的逻辑嵌套问题，严重拖慢业务逻辑的开发。

正因为这样，所以才更需要发布订阅者模式。