在NServiceBus documentation中有声明说sagas不应该调用Web服务：
除了与自己的内部状态进行交互之外，saga不应该访问数据库，调用Web服务或访问其他资源 - 既不直接也不间接注入此类依赖项。
由于没有解释为什么不这样做，我想请社区帮助我解决这个问题。
我理解为什么我无法查询数据库：在发布事件及其处理之间状态可能已经发生了变化。我不理解的部分是关于Web服务。
为什么POST是不好的做法让我们说使用给定ID的ShipOrder发送带有命令的web服务？
答案 0 :(得分：2)
通过https://discuss.particular.net/或通过常规支持向特定软件团队提出此类问题通常会更好。原因是这些问题相当开放，往往会产生一个回复的帖子。
由于我在使用特定软件，请在此处继续操作。您可以随时复制问题/主题。
主要原因是传奇国家的争用和一致性。根据持久性，可以使用悲观锁定或乐观锁定来检索并保留saga状态。无论哪种方式，如果事务花费的时间太长，可能会出现另一条与同一个传奇实例相关的消息。它可能在不同的（并发）线程（或者可能是扩展的端点）上处理，并且会立即失败（悲观锁定）或尝试持久化状态（乐观锁定）。将重试该消息。
这是正常行为，而不是可以避免的事情。但是，锁打开的时间越长，发生的可能性就越大。通常的建议是除了编排业务流程之外不要做任何其他事情。因此，甚至不检索或存储您自己的业务数据。但是使用web服务，您无法控制Web服务，并且可能需要连接超时，或者在消息失败之前更长时间。相关消息将更快失败，并且它们可能最终会在错误队列中结束。
除了协调业务流程之外，不做其他任何事情都可以避免的事情只是＆＃39;发送信息。保持对数据的锁定尽可能短。
答案 1 :(得分：1)
除了Dennis的功能性答案之外，我还觉得这里有代码健康/代码架构的各个方面，特别是关注点的分离。 saga的功能是orcehstration - 为长期运行的业务流程建模。我建议使用saga调用一个方法的成本反过来使web服务调用非常低，并且代码运行状况的增加相对于成本而言是很大的。
换句话说，我建议业务逻辑是业务逻辑，而调用Web服务更像是基础架构代码而不是业务逻辑。
这种区别很重要有很多原因，但需要立即考虑的是您的测试策略。对于基础架构代码，您可能会有一个与业务逻辑测试策略不同的测试策略。当一个班级混合使用时，这很难做到。