考虑一个Web应用程序，除了查询（即添加，更新，删除）作为NServiceBus消息之外，实现每个数据库操作，这样每当用户调用Web API时，在后端它将被映射到 await endpointInstance.Request 方法以返回响应在相同的HTTP请求连接中 .
挑战在于消息处理程序需要发送一些其他消息并等待其响应才能完成其工作 . NServiceBus不允许在消息处理程序中调用 Request .
我最终使用Saga来实现依赖于其他一些消息处理程序响应的消息处理程序 . 但Saga的问题是我无法在同一个HTTP请求中发回结果，因为Saga使用发布/订阅模式 .
我们所有的Web API都需要在同一个HTTP请求中响应（连接应该保持打开状态，直到收到结果或发生超时异常） . 有没有干净的解决方案（最好不使用Saga）？
示例场景：
-
网络服务器调用
await endpointInstance.Request<PurchaseResult>(new PurchaseMessage(itemId, paymentId)); -
PurchaseMessage处理程序应调用await endpointInstance.Request<AddPaymentResult>(new AddPaymentMessage(paymentId)); -
如果
AddPaymentResult成功，则将购买详细信息存储在数据库中并返回true作为PurchaseResult，否则返回false
1 回答
您正在努力实现我们（特定软件公司）试图积极防范的事情 . 让我解释 .
使用远程过程调用（RPC），您可以在进程外调用另一个组件 . 那是什么让程序调用'remote' . 在常规编程的情况下，您可以在进程中执行所有操作并且速度非常快，使用RPC会产生序列化，延迟等开销 . 基本上，你必须处理the fallacies of distributed computing .
人们仍然出于各种原因这样做 . 有时因为您想要使用WebAPI（或“老式”Web服务），因为它提供了您不想开发的功能 . 本书中最古老的例子是通过邮政编码搜索地址 . 或从某人的银行帐户中扣除款项 . 如果您正在构建CRM，则可以使用这些远程组件 . 如今，很多人 Build 了分布式的巨石，因为他们在 Session 上被教导这是一件好事 . 在架构图中，它看起来非常好，但仍然存在时间耦合，可能会带来很多麻烦 .
其中一些令人头疼的问题来自于你正试图在原子动作中做事 . 在这些日子里，通过进程调用代码/类/等，这很简单快速 . 直到你遇到限制，比如数据库上的大量锁 .
解决方案是异步通信 . 你通过“一劳永逸”发送一些信息 . 这解决了时间耦合 . 而不是让数据库获得数十个和数十个更新数据等的请求，结果，您的网站停滞不前，您有各种选择来确保不会发生这种情况 . 这是一件非常好的事情，因为您可以使用各种较小的操作和多种分布式工作方式，扩展系统等，而不是单个原子操作 .
它还带来了额外的挑战，因为不是每个人都能够一劳永逸地工作 . 一些已经构建的系统尝试通过消息传递引入异步通信（希望NServiceBus） . 有些部件可以完美地工作 . 但其他部分不能 . 主要是用户界面（UI） . 因为它的 Build 是为了立即获得结果 . 因此，当您从UI发送消息时，您希望得到一个结果！
通过NServiceBus，我们构建了一个名为“Client-Side Callbacks”的软件包，以实现这一目标 . 我们强烈建议客户不要使用它，除了我刚才描述的这个特定场景 . 迁移整个UI以便能够处理您没有得到即时答复的事实要好得多，但我们知道这是太多的工作，没有多少人能够实现这一目标 .
但是，一旦发送了第一条消息并且UI收到了结果，就不再需要使用回调 . 因此，我想提出这种情况：
使用电话http://test.com/purchase?itemId=5&paymentId=133
网络服务器调用
await endpointInstance.Request<PurchaseResult>();PurchaseMessage处理程序检索所需的信息，并向（一）其他组件发送或发布消息，然后回复给Web服务器并给出答案 .下一个处理程序与发送/发布消息一起使用并继续该过程
如果您需要更多信息，请告诉我们 . 您可以随时发送电子邮件至support@particular.net与我们联系