NServiceBus 不显眼的约定 DefineCommandsAs 多次

标签 nservicebus convention unobtrusive

看来我不能多次定义命令/事件约定。每个注册的约定都会覆盖之前的约定。

这有效:

 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 接口(interface)(我不想这样做,引入 Unobtrusive 模式是有充分理由的),要么提出一些约定,例如所有命令都必须驻留在 *.Commands 中。 * 我也不喜欢的命名空间。

所以问题是如何让包以不显眼且透明的方式向主机注册它自己的约定。

编辑

我能想到的解决这个问题的另一种方法是实现一个共享约定单例并将约定注册委托(delegate)给它。然后,该单例将记住所有约定,并每次都会继续附加它们。不漂亮,但并不比其他两种选择更难看。

最佳答案

消息约定不支持多个调用绝对是设计使然。这是为了防止对一条消息可能有多种意见。让它们成为累加性意味着任何人都可以发表意见。

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

我确实为 Pspecial 工作,所以虽然没有什么是一成不变的,但我可以相当有信心地说,没有计划在 V6 中改变这一点。

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

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

关于NServiceBus 不显眼的约定 DefineCommandsAs 多次,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/34205642/

相关文章:

nservicebus - 影响NServiceBus消息处理速度的因素有哪些?

azure - NServiceBus 和 Azure 长时间运行处理程序模式

nhibernate - 运行 NServicebus 服务时出现死锁导致连接损坏

Python 约定 : should I normally call the super class' __init__?

css - 为什么颜色在 CSS 中用十六进制值表示?有历史解释吗?

NServiceBus:订阅具有特定属性值的事件

用于存储所有已定义字符串的 Java 约定

asp.net-mvc-3 - jQuery.validator.unobtrusive.adapters.addMinMax 往返,在 MVC3 中不起作用

jQuery 按钮处理程序与内联 onClick