NServiceBus 不显眼的约定多次将命令定义为

Question

似乎我不能多次定义命令/事件约定。每个注册的约定都将覆盖以前的约定。

这有效：

 configuration.Conventions()
            .DefiningCommandsAs(
                type => type.FullName == "MyProject1.CommandA" || type.FullName == "MyProject2.CommandB");

但这不会：

        configuration.Conventions()
            .DefiningCommandsAs(
                type => type.FullName == "MyProject1.CommandA");

        configuration.Conventions()
            .DefiningCommandsAs(
                type => type.FullName == "MyProject2.CommandB");

为什么我需要这个：

我正在开发一个包，一旦在 NSB 项目中引用，它将执行定期操作（发送消息）。它需要定义自己的命令约定，INeedInitialization在程序集扫描期间将采用这些约定。我不希望包的用户知道他需要注册包的约定。然而，宿主项目需要为命令注册自己的约定。因此，目前看来我要么需要求助于 Marker 接口（我不想这样做，这是引入 Unobtrusive 模式的一个很好的理由），要么提出所有命令都必须驻留在 *.Commands 中的约定。 * 我也不喜欢的命名空间。

所以问题是如何使包注册它自己的约定对主机不显眼和透明。

编辑

我可以想到的另一种解决方法是实现共享约定单例并将约定的注册委托给它。然后，该单例会记住所有约定，并且每次都将附加它们。不漂亮，但不比其他 2 个选项丑。

Answer 1

不支持多次调用的消息约定绝对是设计使然。这是为了防止对消息可能是什么有多种意见。让它们相加意味着任何人都可以有意见。

因此，这种模式旨在提供与此相反的摩擦，让您就Command在整个系统中的含义达成一致的定义。基本上，SOA 原则 #4：服务兼容性基于策略。很多时候这是“以”结尾的命名空间.Commands模式；我个人使用过那个，效果很好。

我确实为 Particular 工作，所以虽然没有什么是一成不变的，但我可以有理由自信地说，在 V6 中没有改变这一点的计划。

如果您绝对需要做一些不同的事情，那么您在 Edit 中创建某种MessageRegistry单例并拥有约定委托的想法MessageRegistry.IsCommand(Type)是完全有效的。在 V5 中，在总线启动之前不会执行任何操作，因此只要在总线启动之前填充 MessageRegistry（这也可以从内部完成INeedInitialization），那么一切都应该运行良好。

如果您确实沿着这条路线走下去，我鼓励您一路走下去，让您的注册表单例负责其他元数据，如 TimeToBeReceived、DataBus、WireEncryptedString、Express 以及任何其他基于属性的消息元数据。