Azure Service Bus序列化类型

我们已经开始调查使用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; 在我们的旧队列中，这是二进制序列化的，因此它可以更快地存储并保留其元数据。 这对我们很重要，因为我们使用队列使用此处概述的模式发送命令，接收工作者角色使用generics和动态类型的混合反序列化命令。

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

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

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

Answer 1

根据文件 ：

应用程序可以通过将任何可序列化对象传递给BrokeredMessage的构造函数来设置消息体，然后使用相应的DataContractSerializer来序列化对象。 或者，可以提供System.IO.Stream。

您正在使用的构造函数具有以下文档 ：

通过使用带有二进制XmlDictionaryWriter的DataContractSerializer，从给定对象初始化BrokeredMessage类的新实例。

这非常适合定义为DataContracts的消息，如本文所述 。

或者，您可以使用此答案中描述的代理人。

您还可以提供自己的序列化程序或流 。

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

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