17

サービス指向アーキテクチャへの移行に伴い、現在のキューの代わりとして 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です。私たちの古いキューでは、これはバイナリ シリアル化されていたため、より高速に格納でき、メタ データを保持できました。これは、キューを使用して、ここで概説したパターンを使用してコマンドを送信し、受信側のワーカー ロールがジェネリックと動的型付けを組み合わせてコマンドを逆シリアル化するため、私たちにとって重要です。

ただし、この記事によると、コンストラクターに渡される本体BrokeredMessageは「バイナリ XML シリアル化」です。私の仮定では、これは標準の XML シリアライゼーションであり、バイナリ フォーマッタを介して渡されますが、それは正しいですか?

これに加えて; それは、デフォルトのBrokeredMessageメッセージ本文機能を使用する場合、ということですか。存在するすべての問題を含め、すべてのオブジェクトが XML シリアライズ可能であることを確認する必要がありますか? (プライベート フィールドの損失、ジェネリックを使用した逆シリアル化のためのメタ データなし、xml シリアル化属性)

ついに; このような場合は; これを回避する簡単な方法はありますか？独自のバイナリ シリアライゼーションを実行してbyte[]から、 のプロパティに を格納することを検討していましたBrokeredMessage。

4

1 に答える 1

22

ドキュメントによると：

アプリケーションは、任意のシリアル化可能なオブジェクトを BrokeredMessage のコンストラクターに渡すことによってメッセージの本文を設定できます。その後、適切な DataContractSerializer を使用してオブジェクトをシリアル化します。または、System.IO.Stream を提供することもできます。

使用しているコンストラクターには、次のドキュメントがあります。

バイナリ XmlDictionaryWriter で DataContractSerializer を使用して、指定されたオブジェクトから BrokeredMessage クラスの新しいインスタンスを初期化します。

これは、この記事で説明されているように、DataContracts として定義されたメッセージに適しています。

または、この回答で説明されているようにサロゲートを使用することもできます。

独自のシリアライザーまたはストリームを提供することもできます。

別の方法として、独自のシリアル化を行い、(メッセージ プロパティではなく) コンストラクターに提供されるシリアル化可能なオブジェクトとしてバイト配列または文字列を使用することもできます。JSON やprotobufなどのシリアル化形式を使用できるため、これは相互運用性に適したアプローチです。Microsoft 独自のWindows Azure アプリケーションのパフォーマンスに関するベスト プラクティスでは、パフォーマンスに影響する場合は、カスタムまたはサード パーティのシリアル化を使用することを推奨しています。

JSON シリアライゼーションと動的オブジェクトを使用して、良い結果が得られました。

于 2013-07-10T17:47:39.733 に答える