【发布时间】：2016-06-02 15:05:49
【问题描述】：
我阅读了这篇关于 NserviceBus Sagas 的优秀教程 (http://blogs.planbsoftware.co.nz/?p=247)，但我仍然不明白这种模型 (sagas) 与使用数据库或业务层事务相比有什么优势？
【问题讨论】：
标签： nservicebus nservicebus-sagas
【发布时间】：2016-06-02 15:05:49
【问题描述】：
saga 模型的主要好处是，它允许您获取原本会分散在整个系统（以及各种批处理作业）中的逻辑和数据，并将它们全部放入一个类中，更好地遵循单一职责原则。一旦你有了这些，你就会获得来自良好软件实践的所有其他好处——更好的可测试性、可维护性等。
【讨论】：
-
非常感谢乌迪。你能给我指出一个简单的虚拟示例，它以两种方式实现某些东西，所以我真的能理解其中的区别吗？我同意状态数据将分布在整个系统中，但也许我存在的问题是：如果该数据成为业务流程的一部分（我们可能需要查询该状态数据以获取报告，让客户知道当前状态等）将状态数据与业务数据一起存储没有意义吗？再次感谢。
-
我会把下一个放在要做的事情列表中:) 但说真的，你完全可以直接查询传奇数据 - 它被持久化到常规数据库。
-
我想我明白了……所以使用 SagaData 的进程充当分布式事务协调器，可以访问事务中涉及的多个系统中的状态，对吧？
-
我根本不会这样描述它。 saga 类是唯一对 SagaData 进行操作的类。使用 saga 时，各种系统之间的任何协调都将以非事务性消息驱动的方式完成。
为了向您展示 Saga 模型的真正好处，我将向您展示两个示例。
想象一下，您拥有包含数百个分布式主机的面向服务的体系结构。客户下订单，开始一个或多个 sagas。每个 saga 都有一些相关的业务逻辑。每个给定 saga 的处理程序可以在不同主机之间共享，您无需检查处理每条消息的订单状态，NServiceBus 隐式检查通过订单 id 或其他属性匹配它的 saga 状态，如果它仍然打开，您将获得它您的数据上下文。
您也可以将此模型用作不使用 NServiceBus 的模式。想象一下，您开发了一个视频游戏并想要跟踪一些用户组合。每次玩家点击跳跃时，您都会打开传奇并添加处理其他快速输入的奖励积分。一旦玩家在输入之间延迟一段时间，saga 会自行关闭，从而节省组合总分。
Saga 有什么好处？
1) 您的业务逻辑被封装在一个地方 - saga。
2) 您可以轻松地扩展它，添加额外的 saga 或删除它们。您还可以将它们移动到其他处理程序或主机。
3) 迁移时不需要知道数据库中需要哪些数据，只需要迁移包含所有必要信息的 sagas
【讨论】：