architecture - 使用 NServiceBus 时如何跨应用程序共享消息类？

Question

所以我有两个独立的应用程序，我想在它们之间发送消息。我碰巧在使用 NServiceBus，但这并不重要。如何从应用程序 A 向应用程序 B 发送消息并让他们都知道同一个合同？

所以应用 A 有一个 SecretMessage 类...

public class SecretMessage : IMessage
{
     public string Title { get; set; }
     public string Body { get; set; }
}

这是将被序列化并通过线路发送到应用程序 B 的对象。

现在在应用程序 B 中，我如何侦听该类型的消息，然后能够将它们反序列化到同一类？所以我可以使用发送的数据，而不会成为维护的噩梦。

应用 B 是否只需要拥有该课程的副本？这是否应该通过每个应用程序都引用的消息类的共享 dll 来处理（我希望不是）？是否应该在每个应用程序中将它们重新创建为具有相同属性的完全独立的 DTO？

我在这里错过了什么吗？

score 6 · Accepted Answer

这可能不是您想要的答案，但这里的灵丹妙药很少。

您实际上只有几个选择，因此取决于您希望消息类中的功能级别和类型强化：

共享 DLL 的好处是它可以是代码 + 结构，例如有用的构造函数、复杂的枚举器、调试 ToString 实现等。强大的版本控制。DLL 需要单独的项目和分发。
共享模式和代码生成。为您的类型声明架构并使用代码生成来创建类。这里有很多不同的策略 - 一些示例：T4 模板、自定义代码生成、工具和库，例如CodeSmith或Proto.Bufs。搜索会发现您加载更多。可以非常强大 - 知道许多代码商店，它们通过使用 CodeGen 从 DB 到 UI 的快速原型设计来启动所有项目。您仍然需要分发架构。
以足够的保真度序列化消息以通过 Code DOM 生成类型。每条消息都会产生携带足够类型元数据以代表它的所有消息实例的成本。例如可空字段的表示。生成消息包装器类型也会有内在的第一次“发现”成本。
以弱结构（例如名称/值对）序列化数据，然后生成类似字典的包装类。弱类型 - 易于扩展。

这些真的是唯一的选择。恕我直言，按此顺序排列的 #2 和 #1 通常是最有用的模式。

score 2 · Accepted Answer

正如Juval Lowy 在 Programming .NET Components 中所建议的那样，在它们自己的共享 DLL 中分离纯接口。

2 回答 2