Event communication in Facebook flux and other flux lib

[switer]

• 在 Pub/Sub 中，每个订阅者同时也是发布者，该模式拥有天然的双向通信特性。
• Pub/Sub 是一种类似广播代理机制，事件为通信载体，发布者与订阅者不需要知道相互之间的存在。例如：A 不需要知道 事件 E 是 B 还是 C 发出来的。
• Observer 模式下，观察者向对象订阅，双方需知道相互的存在。

  Lib

flux 为 Facebook 官方发布 flux 库，reflux 为一个实现 flux 模式的第三方库。

flux

• ViewController 直接调用 Action
• Action 通过 Dispatcher （Pub/Sub） 与 Store 通信
  • 由于 Dispatcher 为一个全局的 Pub/Sub 模块，所有的Action 在全局范围内都可以与 Store 都可以进行相互通信
• ViewController 通过观察者模式，订阅 Store 的信息

  reflux

• ViewController 直接调用 Action
• Store通过观察者模式，订阅 Action 信息
• ViewController 通过观察者模式，订阅 Store 的信息

  差异

Flux 使用 Pub/Sub 作为 Action 与 Store 的通信机制。

• Action 与 Store 无直接依赖关系。
• Store 只需要向 Dispatcher 订阅多重信息，然后根据载体信息来执行具体行为（载体信息还需要携带来源信息来区别事件来源，以便 Store 区别信息的合法性）。

在 reflux 中，Action 使用 Observer 替代全局 Pub/Sub 与 Store 通信。

• 两者都必须知道对方的存在，Action 与 Store 之间耦合。 如果单个模块为单个 Action 和 Store 实例的载体的话，模块之间存在依赖关系。
• Store 当需要订阅多个 Action 的信息，那么就需要依赖多个 Action 模块，但事件载体不需要携带来源信息。

  More

• reflux 弱化了 Action 的职责，把 Action 抽象为简单的事件代理器，提供 ViewController 发布行为事件的功能与及Store 订阅事件信息，作为 ViewController -> Store 单方向的事件桥梁。
• 这样的好处在于，在简单的行为逻辑下，VC 执行完毕具体的行为逻辑后，通过 Action 把结果发布给 Store ，一切简单又轻巧。
• 但在更复杂的场景下，不能把全部行为逻辑写在VC里面，那样就太臃肿难维护了，而且抹杀了行为逻辑的服用性。Flux 把行为逻辑封装在Action，然 Action 自发与 Store 通信，VC 只关系，执行了一个 抽象行为，然后等待 Store通知数据更新，且 Action 里面封装的行为可以被其他的 VC 复用。