3

次のようなクラスのシリアル化コードを記述しようとしています。

public class EventMessage
{
    public Dictionary<string, object> Headers { get; set; }
    public object Body { get; set; }
}

このクラスの「オブジェクト」型メンバーは、非常に小さな (基本的に、1 つのアセンブリ + 基本的な CLR 型に制限されている) 型セットのオブジェクトを保持します。したがって、これらのクラスを次のようにオブジェクトクラスのサブタイプとして簡単にリストできると考えました。

model.Add(typeof(object), false)
    .AddSubType(1, typeof(X))
    .AddSubType(2, typeof(Y))
    ....

この方法では、オブジェクト クラス自体の逆シリアル化が switch ステートメントのように機能するため、シリアル化されたメッセージに型情報を埋め込む必要がありません。メッセージに存在するタグの 1 つをチェックし、適切な型に逆シリアル化します。クラスの名前を自由に変更し、オブジェクトを壊すことなくアセンブリ内で移動できるため、これが気に入っています。

これは、主に文字列データを含むヘッダーのテストを開始するまで、私のテストではうまく機能しました。この例外が発生しているため、文字列をオブジェクトのサブタイプとしてマークできません。

Data of this type has inbuilt behaviour, and cannot be added to a model in this way: System.String

この動作を実現する方法はありますか、またはそのようなクラスをシリアル化するためにメッセージ内に型情報を埋め込む必要がありますか?

4

3 に答える 3

2

埋め込もうとしている文字列をカプセル化した「メッセージ」または同様のクラスを追加できませんでしたか

class Message
{
  [ProtoMember(1)]
  string Data {get;set;}
}
于 2012-07-25T05:44:44.453 に答える
2

protobuf-net は構造化データを保存します。objectは本質的に構造化されておらず、単純に のサブクラスを宣言することも、シリアライゼーションに非常に特殊なルールを持つobjectなどの基本的な型を操作することもできません。string

これは私のテストでうまくいきました

もしそうなら、それはバグです。それがうまくいく方法はありません。まったく。これは確かにサポートされているシナリオではなく、正しいことを保証するものではありません (物事が大幅に壊れる可能性もあります)。この場合、明示的に例外を発生させるようにコードを変更します。できるだけ早く修正するために、次を追加しています。

うーん....これは無効なシナリオでしたが、私の回帰テストでは、これには「先行技術」がいくつかあることが強調されています。

（これが、重要なprotobuf-netの質問に答えるたびに、回帰テストとして追加するため、嘘をついていませんでした）

私はそれを除外すべきではないと思いますが、子猫のことを考えてください。それは私の推奨する方法ではありません. 今は殺せないと思うけど。ただし、強調:サブタイプとして (etc)を追加するためにこれを有効にすることはできません。stringカスタムclass/を意味する API メッセージタイプのみを考慮してくださいstruct。

この方法では、オブジェクト クラス自体の逆シリアル化が switch ステートメントのように機能するため、シリアル化されたメッセージに型情報を埋め込む必要はありません。

通常、protobuf-net も型情報を埋め込みません;p 型情報を含む「動的」サポートがいくつかありますが、このシナリオでは必要ありません。

型情報を埋め込まずにこれを行うためにサポートされている方法は、次のように、必要な値をカプセル化することです。

[TestFixture]
public class SO11641262
{
    [Test]
    public void Execute()
    {
        var model = TypeModel.Create();
        model.Add(typeof (FooData), true)
            .AddSubType(1, typeof (FooData<string>))
            .AddSubType(2, typeof (FooData<int>))
            .AddSubType(3, typeof (FooData<SomeOtherType>));

        var val = FooData.Create("abc");
        var clone = (FooData)model.DeepClone(val);
        Assert.AreEqual("abc", clone.ValueUntyped);
        Assert.AreEqual(typeof(string), clone.ItemType);

    }

    [ProtoContract]
    public abstract class FooData
    {
        public static FooData<T> Create<T>(T value)
        {
            return new FooData<T> {Value = value};
        }
        public abstract Type ItemType { get; }
        public abstract object ValueUntyped { get; set; }
    }
    [ProtoContract]
    public class FooData<T> : FooData
    {
        [ProtoMember(1)]
        public T Value { get; set; }

        public override Type ItemType
        {
            get { return typeof (T); }
        }
        public override object ValueUntyped
        {
            get { return Value; }
            set { Value = (T) value; }
        }
    }
    [ProtoContract]
    public class SomeOtherType {}
}
于 2012-07-25T06:43:29.750 に答える
0

うーん..オブジェクトから継承するCLRプリミティブ型か、カスタム型かは問題ではないと思います。継承された型として登録されている場合は、どのような方法でも機能するはずです。私が理解している限り、一般的にはそのような構造でシリアル化されています

object
{
  A: {..., AA: {}}
  B: {..., BB: {}}
}

class A{ ... } 
class A: AA { ...}

class B {...}
class BB : B {...}

次のような追加の継承を追加しても何にも影響しないはずです

object
{
  A: {..., AA: {}}
  B: {..., BB: {}}
  String: 'asdf'
}

文字列のシリアル化を変更していないため、String を継承オブジェクトとして追加するだけです。同じ問題は、intまたはその他のプリミティブ型が必要な場合です。

于 2012-07-25T14:24:14.610 に答える