NServiceBus 和 WCF，它们如何相处？答案

【问题标题】：NServiceBus and WCF, how do they get along?NServiceBus 和 WCF，它们如何相处？
【发布时间】：2015-12-15 05:37:15
【问题描述】：

简化...我们正在使用 NServiceBus 来更新我们的存储。

在我们的 sagas 中，我们首先从存储中读取数据并更新数据并将其再次放回存储中。NServicebus 实例自托管在 Windows 服务中。对存储的调用在其自己的程序集（“assembly1”）中分开。

现在我们还需要通过 WCF 从存储中同步读取。在某些情况下，在 sagas 中更新时需要相同的读取。

我的意见很清楚，但也许我错了，所以我问这个问题......

我们是否应该设置一个使用“assembly1”副本的单独 WCF 服务？或者，WCF 实例是否应该托管 nservicebus？或者，还有更好的方法吗？

它在某种程度上是两个端点，用于同步调用的 WCF 和现在托管 nservicebus（已经存在）的 Windows 服务。

【问题讨论】：

在某些情况下，在 sagas 中更新时需要进行相同的读取 - 你的意思是 sagas 将调用 WCF 服务吗？
这是一种方法，但今天没有 WCF 服务（但...待定）。 sagas 直接通过“assembly1”调用存储。事情是以相反的顺序完成的。没有完整的架构，现在我们需要把它改正。
那么您的问题是，您的 WCF 服务是出于架构原因还是出于功能原因（即您需要将端点公开为 WCF 服务）而独立于您的 NSB 端点？抱歉，我不明白您最终要达到的目标。 WCF 服务将被 NSB 使用，还是您只是通过 WCF 提供另一条进入数据库的路由并且担心争用等？
好的。我应该让我们的 WCF 服务独立于现有的 NSB 端点吗？ NSB 不会使用 WCF 服务。不过，也许这正是我们应该做的……我只想将 WCF 用于读取。但是我们也有需要进行更新的场景，即从我们的最终用户应用程序向 NSB 发送（命令）消息。

【解决方案1】：

我认为没有理由在您的问题或 cmets 中分成两个不同的端点。听起来您正在描述单个逻辑服务，而我的默认位置是在单个进程中托管每个逻辑服务。这通常是最简单的方法，因为它使部署和故障排除更加容易。

编辑

不确定这是否有用，但我当前的客户端在 IIS 托管的 WCF 端点中运行 NSB。所以命令是通过 NSB 消息处理的，而查询仍然通过 WCF 公开。迄今为止，我们在一个进程中将两者托管在一起没有任何问题。

【讨论】：

【解决方案2】：

一般来说，saga 应该只更新自己的状态（Data 属性）并将消息发送到其他端点。它不应更新其他状态或进行 RPC 调用（如 WCF）。

在给出更具体的建议之前，最好更多地了解您的 saga 的具体职责以及“assembly1”正在更新的数据。

【讨论】：