NServiceBus 回复消息警告答案

【问题标题】：NServiceBus Reply Message warningNServiceBus 回复消息警告
【发布时间】：2012-09-12 00:07:20
【问题描述】：

我有一个使用 NServiceBus 的 ASP.Net WebAPI 应用程序。命令从应用程序发送到运行 NSB 主机的后端服务器。服务器负责与数据库通信。

大多数命令都是即发即弃的。一个简单的 Bus.Send(...) 并立即释放 Web 客户端，因此操作可以异步发生。

例外情况是在数据库中创建新记录的命令。数据库负责生成新创建实体的 ID，我需要将其返回给调用者。由于调用者必须留下来，所以性能较差，但在我的情况下这是可以接受的。

我成功地为此使用了 Bus.Reply() 功能，如全双工示例中所述。我正在回复一条消息，其中包含新生成的 ID 的单个属性。在 Web 端，我使用任务延续注册回调（利用 WebAPI 的异步能力），并在 Bus.Send() 之后使用 .Register。

这一切都很好。它以一种非常直接和简单的方式完成了我想要的。唯一的问题是客户端每次收到响应消息时，都会记录如下警告：

2012-09-11 16:46:44,745 [Worker.26] WARN  NServiceBus.Unicast.Transport.Transactional.TransactionalTransport [(null)] - Failed raising 'transport message received' event for message with ID=1faee572-f904-4b09-b1d5-c0bd7c12738d\82936
System.InvalidOperationException: No handlers could be found for message type: MyProject.Messages.MyEntityCreatedResponseMessage
   at NServiceBus.Unicast.UnicastBus.HandleTransportMessage(IBuilder childBuilder, TransportMessage msg)
   at NServiceBus.Unicast.UnicastBus.TransportMessageReceived(Object sender, TransportMessageReceivedEventArgs e)
   at System.EventHandler`1.Invoke(Object sender, TEventArgs e)
   at NServiceBus.Unicast.Transport.Transactional.TransactionalTransport.OnTransportMessageReceived(TransportMessage msg)

我怎样才能摆脱这个警告？我这里不需要消息处理程序。

【问题讨论】：

在我的脑海中 - 我认为您需要实现一个虚拟（空）处理程序。否则，您的 MyEntityCreatedResponseMessage 事件将最终出现在错误队列中
一个虚拟处理程序停止了警告，但随后我收到一个不同的警告，说我正在做没有事件的 pub/sub... 为什么它认为 .Reply 应该像我一样被处理做了一个.Publish？？
我发现如果我使用 Bus.Return 而不是 Bus.Reply，我可以在没有任何错误或警告的情况下完成我所追求的。但是，这仅有效，因为我将新 ID 视为错误代码，而我的 ID 恰好是整数。如果我需要传递不同类型的 ID 或任何其他信息（如实际的错误代码），那么这是行不通的。

标签： nservicebus

【解决方案1】：

我建议在服务器甚至客户端（浏览器）上创建 ID。这样您的消息仍然可以是即发即弃的，并且您不需要同步任何内容。

如果您想使用数据库驱动的 ID 进行持久化，NServiceBus 只会增加开销。不妨从您的网站代码直接与数据库对话，并在那里添加重试。

【讨论】：

这将需要 GUID 标识符之类的东西。如果可能的话，我想坚持一个简单的自动递增整数。直接写入数据库而不是通过总线将是一种选择，但它会绕过我的架构的其余部分，所以我不确定我是否想走那条路。真的，我只是希望回复消息不需要处理程序。
没有说明必须使用 GUID 将实体持久化到数据库中。所有 GUID 需要用于识别用于持久化实体的消息并关联回复。在这种情况下，GUID 将由客户端创建。
@Matt，您不必为整个项目（或系统）使用相同的架构。如果架构妨碍了最佳解决方案，那么它就是错误的架构。想想在同步调用期间会发生什么。 Web 请求到达，被转换为 MSMQ 消息，消息被处理，回复被转换为 MSMQ 消息，虚拟消息到达并被处理，然后回复被发送回 Web 客户端。所有这些开销，有什么好处？
@Rich，我实际上是在建议类似 Guid 的东西。并让信息真正做到一劳永逸。客户端（或服务器）可以伪造对用户的回复。
我将把它标记为答案，因为最终这会产生更好的解决方案。另外，我找到了一种在前端生成我的 id 的方法，所以我根本不需要这个。