Azure服务总线序列化类型
本文关键字:类型 序列化 总线 服务 Azure | 更新日期: 2023-09-27 18:22:01
随着我们向面向服务的体系结构迈进,我们已经开始研究使用Windows Azure服务总线来替代我们当前的队列。
大多数文件都很清楚;然而,我很难确定CCD_ 1在提供主体时使用哪种类型的序列化。
例如,假设我实例化一个BrokeredMessage
对象,如下所示:
ICommand sendMessageCommand = new SendMessageCommand
{
Title = "A new message title",
Body = "A new message body"
};
BrokeredMessage brokeredMessage = new BrokeredMessage(sendMessageCommand);
queueClient.Send(brokeredMessage);
CCD_ 3是用CCD_ 4属性标记的简单DTO;在我们的旧队列中,它是二进制序列化的,因此可以更快地存储并保留元数据。这对我们来说很重要,因为我们使用队列来发送命令,使用这里概述的模式,接收Worker Role使用泛型和动态类型的混合来取消对命令的序列化。
然而,根据这篇文章,传递给BrokeredMessage
构造函数的主体是"Binary XML Serialized"。我的假设是,这是标准的XML序列化,然后通过二进制格式化程序,这是正确的吗?
除此之外;这是否意味着如果我使用默认的BrokeredMessage
消息主体功能;我必须确保所有对象都是可XML序列化的,包括出现的所有问题?(专用字段丢失,没有使用泛型进行反序列化的元数据,xml序列化属性)
最后;如果是这样的话;有简单的方法吗?我正在考虑进行我们自己的二进制序列化,然后将byte[]
存储在BrokeredMessage
的一个属性中。
根据文档:
应用程序可以通过传递可序列化对象到BrokeredMessage的构造函数,并且然后将使用适当的DataContractSerializer来序列化对象或者,可以提供System.IO.Stream。
您使用的构造函数有以下文档:
从给定的初始化BrokeredMessage类的新实例对象,方法是将DataContractSerializer与二进制文件一起使用XmlDictionaryWriter。
这非常适合定义为DataContracts的消息,如本文所述。
或者,你可以使用这个答案中描述的代孕。
您还可以提供自己的序列化程序或流。
另一种选择是自己进行序列化,并使用字节数组或字符串作为提供给构造函数的可序列化对象(而不是在消息属性中)。这是一种充分的互操作性方法,因为您可以使用JSON或protobuf等序列化格式。Microsoft自己的Windows Azure应用程序性能最佳实践建议在影响性能时使用自定义或第三方序列化。
我使用JSON序列化和动态对象取得了很好的结果。