如果有任何数据是可选的，将没有围绕它的测试。但需要更少的代码，需要能更具扩展性，特别典型的是能自解释（感谢这些成员名字）以便能在逐一传送给订阅者回调方法时，对一个对象进行那种测试。我仍然在不得不用"0-n参数"的地方用它，但如果由我决定，将是一直用封套的方法——我的事件发送者和消息总线都是这样。（说明我存在偏见，monologue与postal共享同一个封套的数据结构，去掉了monologue不用的通道）
因此——得承认用来给订阅者传输数据的结构是”合约“的一个部分。在封套方式这个方向，你可以用额外的元数据描述事件（不需要增加额外的参数）——这保持了方法签名（这就是合约的一个部分）对每个事件和订阅者一致。你也能很容易的为一个信息结构编制版本（或在必要的时候增加其他封套层级的信息）。如果你沿着这个方向做的话，请确保用的是一致的封套结构。
6.) 消息”拓扑“比你想的还重要
这里没有银弹。但是你要对如何命名主题与通道，以及如何设计消息载荷的结构深思熟虑。我倾向于用两种方法之一映射我的模型：用一个单一的数据通道，主题的前缀采用模型的名字，后跟其唯一的id，然后通过它的操作({modelType.id.operation})处理，或者给模型的自身通道，主题就是{id.operation}。一个恒定的习惯是在模型请求数据的时候自动响应这个行为。但并不是所有总线上的操作都是请求。可能有简单的事件发布到app。你是否命名主题来描述事件（理想条件下）？或者你是否掉进了这样的陷阱，通过命名主题来描述某个订阅者可能的倾向行为？例如，包含“route.changed” 抑或 “show.customer.ui”主题的消息。一个表明了事件，另一个表明了命令。做这些决定的时候要仔细思考。命令并不坏，但在你需要请求/响应或命令之前，你会为事件所能描述的数量而吃惊的。
您可能感兴趣的文章: