5

私は今しばらくこれを見てきました

フィールド名を変更するとシリアル化が壊れるため、バイナリシリアル化は推奨されないようです =? 良くない

XMLSerializer には問題があります。これは、属性または要素である要素とその命名をより詳細に制御できますが、引数なしのコンストラクターとパブリック フィールドを提供する必要があるためです。

DataContractSerializer は優れていますが、すべてのサブクラスを明示的に追加する必要があるのは残念です

ただし、この制限がない NetDataContractSerializer に出くわしました。

あなたの目標が C# シリアル化であり、xml のサイズに大きな制約がない場合、NetDataContractSerializer は常にここに行く方法ですか??

4

2 に答える 2

11

Dan Rigsby は、 XmlSerializer と DataContractSerializerに関する非常に優れた比較記事を執筆しており、NetDataContractSerializer についても触れています。

DataContractSerializer:

  • 高速です - XmlSerializer より約 10% 高速です
  • 相互運用可能 - Java、Ruby と問題なく動作します。
  • 明示的な「オプトイン」モデルを使用 -シリアル化されるものをマークする必要があります
  • コンストラクタは必要ありません
  • 非公開メンバーと内部フィールドをシリアル化できます
  • XML ノードの属性をサポートしていません

何をシリアル化するかをDCS に明示的に指示しますが、それがどのように行われるかについてはあまり影響を与えません。

XmlSerializer

  • パブリック フィールドとプロパティのみをシリアル化します
  • 除外したものを除くすべてをシリアル化します (オプトアウト モデル)
  • サポート属性とすべて
  • 相互運用可能 - Java、Ruby と問題なく動作します。
  • 逆シリアル化にはパラメーターなしのコンストラクターが必要です

XmlSerializer にシリアル化する方法と対象をかなり明確に伝えますが、すべてをシリアル化することはできません。パブリックに表示されるプロパティのみです。

NetDataContractSerializer は少し変わっています。相互運用性がなく、両端が .NET の場合にのみ機能します。メッセージに .NET 型の情報が含まれます (サイズが大きくなります)。「そのまま」WCF サービスに宣言的に追加することはできません。

いつものように、これは厳しいトレードオフです。下位互換性がなく、壊れやすく、頭痛の種になるバイナリフォーマッターには絶対に近づかないでください。これらの標準的な方法のいずれかを使用してください。与えられたシナリオにどれが「最適」であるかを判断するのは本当に難しいです - 自分でそれを見つけ出す必要があります....

于 2009-12-29T21:29:46.683 に答える
2

Marc Gravellは、彼のブログで、DataContractSerializer、XmlSerializer、およびprotobuf-net（彼が作成した.NET用のProtocol Buffersの実装）を含む他のほとんどの.NETシリアライザーで行ったベンチマークの結果を示しています。

于 2010-01-29T22:16:05.843 に答える