Question

我们已开始调查使用Windows Azure Service Bus作为我们当前队列的替代品，因为我们正朝着面向服务的架构迈进。

大多数文件都很清楚;但是我很难确定BrokeredMessage在提供身体时使用的序列化类型。

例如，假设我实例化一个BrokeredMessage对象，如下所示：

ICommand sendMessageCommand = new SendMessageCommand
{
    Title = "A new message title",
    Body = "A new message body"
};

BrokeredMessage brokeredMessage = new BrokeredMessage(sendMessageCommand);

queueClient.Send(brokeredMessage);

SendMessageCommand是一个标有[Serializable]属性的简单DTO;在我们的旧队列中，这是二进制序列化的，因此它可以更快地存储并保留其元数据。这对我们很重要，因为我们使用队列使用pattern outlined here发送命令，接收工作者角色使用泛型和动态类型的混合反序列化命令。

然而根据THIS文章，传递给BrokeredMessage的构造函数的主体是“二进制XML序列化”。我的假设是，这是标准的XML序列化，然后通过二进制格式化器，是正确的吗？

除此之外;这是否意味着如果我要使用默认的BrokeredMessage消息体功能;我必须确保所有对象都是XML Serializable，包括所有出现的问题？（私有字段丢失，没有使用泛型反序列化的元数据，xml序列化属性）

最后;如果是这样的话;有一个简单的方法吗？我正在考虑进行自己的二进制序列化，然后将byte[]存储在BrokeredMessage的属性中。

Answer 1

根据the documentation：

应用程序可以通过传递任何内容来设置消息正文可序列化的对象到BrokeredMessage的构造函数，以及然后将使用适当的DataContractSerializer来序列化宾语。或者，可以提供System.IO.Stream。

您使用的构造函数有this documentation：

从给定的位置初始化BrokeredMessage类的新实例通过使用DataContractSerializer与二进制文件对象的XmlDictionaryWriter。

这与定义为DataContracts的消息非常吻合，如in this article所述。

或者，您可以使用this answer中描述的代理。

您还可以提供your own serializer或a stream。

另一种方法是进行自己的序列化，并使用字节数组或字符串作为提供给构造函数的可序列化对象（而不是在message属性中）。这是一种适用于互操作性的方法，因为您可以使用序列化格式，如JSON或protobuf。 Microsoft自己的Best Practices for Performance in Windows Azure Applications建议在影响性能时使用自定义或第三方序列化。

我使用JSON序列化和动态对象获得了很好的结果。

Azure Service Bus序列化类型

1 个答案: