【问题标题】:how to avoid compile time dependency to a rebus message?如何避免编译时间依赖于 rebus 消息?
【发布时间】:2017-01-20 12:38:38
【问题描述】:

我想通过上下文 A 引发的事件集成两个有界上下文,并使用上下文 B 中的事件。 我想如何避免编译时间依赖性,所以上下文 B 不必包含上下文 A 的 dll/库。(至少我不希望每次新事件类型获取时都需要更新对 A 的引用的麻烦由上下文 A 暴露。

Rebus 是否有任何首选/最佳实践?

【问题讨论】:

    标签: rebus


    【解决方案1】:

    实际上有几种方法:)

    我自己,我更喜欢将消息作为单独的 NuGet 包分发 - 然后查看packages.config 以查看每个端点具有哪些依赖项。

    只要我保持已发布的消息模式不可变(即遵循严格的仅追加方法来发展它),消费事件就没有问题 - 当反序列化为旧版本的消息模式时,数据会被截断。

    但如果您希望端点的耦合度低于此值,您可以做几件事。

    除非您更改序列化程序,否则消息将被序列化为 UTF8 编码的 JSON。这意味着订阅者始终可以安装自己的 JSON 序列化程序,例如:将消息反序列化为它自己的类型,或者简单地转换为 JObject(假设您使用的是 Newtonsoft JSON.NET)。

    事实上——如果我没记错的话——你可以包含 NuGet 包 Rebus.NewtonsoftJson 并通过去使用它

    Configure.With(new CastleWindsorContainerAdapter(container))
        .(...)
        .Serialization(s => s.UseNewtonsoftJson())
        .Start();
    

    它带来了 Newtonsoft 的 JObject,然后您可以通过实现 IHandleMessages<JObject> 在消息处理程序中使用它。

    希望能给你一些启发:)

    【讨论】:

    • 当然,这是一个很好的线索。我认为这两种选择都很好。
    猜你喜欢
    • 2020-04-06
    • 2014-08-07
    • 2021-08-16
    • 2013-08-22
    • 2014-12-08
    • 1970-01-01
    • 2017-09-27
    • 2018-09-03
    • 1970-01-01
    相关资源
    最近更新 更多