重用 NServiceBus 消息传奇数据

Question

是否有任何理由不在 saga 数据中重用 NServiceBus 消息 (IMessage)？我的意思是有一条像这样的消息：

public class Order : IMessage
{
   public virtual List<TillOrderLine> OrderLines { get; set; }
}

public class TillOrderLine : IMessage { ... }

然后也在 saga 和 saga 数据中使用它，如下所示：

public class OrderProcessingSaga : 
    Saga<OrderProcessingSagaData>, 
    IAmStartedByMessages<Order> { ... }

public class OrderProcessingSagaData : ISagaEntity
{
   public virtual Guid Id { get; set; }
   public virtual string Originator { get; set; }
   public virtual string OriginalMessageId { get; set; }

   // The message data is stored by the saga here.
   public virtual Order Order { get; set; }
}

我意识到消息是由传输层（MSMQ）存储的，而 saga 数据则通过以下方式保存到数据库：传奇。它适用于我当前的用例，并且重用该类似乎更优雅，而不是为消息创建一个类，为传奇存储创建另一个类。

我想知道这种方法是否有任何问题？

Answer 1

我同意 mookid8000 所说的一切，但我还有一个细节需要补充。

您的传奇存储通常会存在很多争用。为了保证一致性，saga 存储提供程序通常会在数据上放置更新锁，以保证来自同一 saga 的另一条消息不能同时改变状态。

如果您使用默认的 NHibernate saga 持久化程序（并且您的虚拟属性向我表明您是这样），那么 NHibernate 使用一些假设来保存您的数据：

• saga 数据中的复杂类型将导致数据库列遵循 ComplexTypePropName_ChildPropertyName 语法（或大约 - 此处根据内存操作）。因此，您的传奇数据仍将包含在一张表的 1 行内。
• 如果您的 saga 数据中有一个列表，那么它显然必须创建一个新表来存储列表项。现在，您的传奇数据包含在一个主行和多个详细行中。
  • 为了让 NHibernate 映射它，您的集合类型还必须有一个名为 Id 的 Guid 属性，这意味着您无法存储基元列表，并且您的 TillOrderLine 类（公共消息的一部分）将需要此 Id 属性这对您的服务的商业目的毫无意义。
• 我不知道如果你的传奇数据中有一个复杂的类型（订单，基本上是重用的消息），它本身包含一个（TillOrderLines）列表，那么你的情况会发生什么。

无论如何，saga persister 需要将数据拆分成的表越多，就越难使用细粒度行锁来锁定涉及的行。如果有足够的争用，行锁将开始升级为页锁和表锁，然后你就真的遇到了问题。

这就是为什么文档数据库真正适合 saga 存储，这就是为什么在 NServiceBus 3.0 中他们将 RavenDB 设为默认的 saga 持久化器。

在此之前，请查看基于 XML 序列化的 Saga Persister我写道，它可以为您今天的应用程序带来即将推出的 RavenDB 风格的传奇持久化程序的一些好处。

如果您必须坚持使用 NHibernate，我强烈建议您不要将消息与 saga 持久性解决方案紧密结合在一起。我几乎可以保证它会在路上再次困扰你。

Answer 2

如果您当前的传奇持久化者没有抱怨地坚持数据，我想不出这种方法有什么问题 - 只要您意识到您正在出于两个目的重用一个类，从而在传奇数据（这是私有的）之间引入耦合 。

然后，如果您需要偏离消息的结构方式，您可以为所有 saga 数据构建类

PS：如果 TillOrderLine 的唯一目的是在 Order 内聚合，则无需将其标记为 IMessage。