2

Type のフィールドを持つClassAタイプを含むプロパティを持つクラスがあります。これを WCF 経由でシリアル化しようとすると、再帰的な性質のために例外が発生しました。解決策は、 のデータ コントラクト定義に追加することでした。 ClassBClassAIsReference=trueClassA

これは素晴らしいことですがClassA、属性でマークされているメンバーがありDataMember(IsRequired=true)、一度追加すると、両方にすることはできず、メンバーを持つIsReference=trueことができないと不平を言いました。 IsReference=trueIsRequired=true

なぜこれが起こるのか理解できません。これに対する回避策があるかどうかを知りたいですか?

xml で必要になるようにデータメンバーを宣言したいのですが?

この投稿はすでに見ましたが、答えはまだはっきりしていません。デフォルト値が発行されないようにしたい場合は、 EmitDefaultValues=false を IsRequired=true と一緒に使用できます (とにかくやりたいことです)。別の回避策はありますか？

4

1 に答える 1

0

逆シリアル化のシナリオを考えてみましょう。DataContractSerializer が読み取っている XML の束があります。IsReference=true および IsRequired=true とマークされている Foo 型を扱っているとします。

シリアライザーは、タイプ Foo のフィールド foo1 を検出します。さて、これは XML が次のようなことを言うことができることを意味します:

<foo1 ref="1" /?

シリアライザーは foo1 を null にデシリアライズしますが、まだ持っていないオブジェクトを参照したことに注意してください。シリアライザーは、残りのフィールドを逆シリアル化します。最終的に、次のような別のフィールドに遭遇します。ああ、foo1 が以前に参照したオブジェクト、つまり ID が 1 のオブジェクトが表示されます。

<foo2 id="1"> <datamember1> ... </datamember1> <datamember2> ... </datamember2> </foo2>

id="1" に遭遇すると、シリアライザーは元に戻り、foo1 が foo2 を指すように修正します。

ただし、foo2 が存在しない可能性もあります。つまり、foo1 は、XML のどこにも存在しない ID を参照している可能性があります。グラフの残りの部分を完全に逆シリアル化するまで、シリアライザーがこれを確実に知る方法はありません。

問題が見え始めることを願っています。型が IsReference と IsReequired の両方である場合、逆シリアル化中に型の IsRequired の性質が尊重されることをシリアル化で保証することはできなくなりました。必要な要素が存在するかどうかを確認できないため、必要な要素が存在しない場合にすぐに失敗することはなくなりました。

于 2011-04-16T04:04:58.797 に答える