Warum muss ich [ProtoInclude] verwenden?

Question

Ich habe viele Fragen zum Vererbungsmerkmal in Protobuf-Net gelesen. Ich frage mich nur, ob ich [DataContract], [DataMember] auf die gleiche Weise verwenden kann wie [ProtoContract], [ProtoMember]. Warum konnte ich [KnowType] nicht verwenden, anstatt [ProtoInclude] zu verwenden?

Ich stelle diese Frage, weil ich bereits [DataContract], [DataMember] für die Serialisierung von Protobuf-Net verwendet habe. Es musste kein "Protobuf-Netz" hinzugefügt werden. Es hat nur "System.Runtime.Serialization" verwendet.

Aber ... Nun, wenn meine Klasse von einer Klasse erben muss, muss ich "Protobuf-net" für [ProtoInclude] -Attribut hinzufügen? zum Beispiel

using System.Runtime.Serialization; 
namespace test 
{ 

[DataContract] 
/// [KnowType(typeof(SomeClass))] 
/// or 
/// [ProtoInclude(100,typeof(SomeClass))] 
public class BaseClass 
{ 
    //... 
    [DataMember(Order=1)] 
    public string BlahBlahBlah {get; set;} 
} 

[DataContract] 
public class ChildClass1 : BaseClass 
{ 
    //... 
    [DataMember(Order=1)] 
    public string BlahBlahBlah {get; set;} 
} 
}// end namespace 

schließlich, frage ich mich, wenn ich 100 Kind-Klasse haben, werde ich mich nicht verrückt machen 100 [ProtoInclude] Tags innerhalb der Basisklasse hinzufügen?

Thx in adv für jede Hilfe

VEE

Answer 1

EDIT: dies ist nicht mehr in v2 erforderlich - Sie diese zur Laufzeit angeben können, oder DynamicType verwenden.

---

Der Grund dafür ist, dass das protobuf Draht-Format (entwickelt von Google) enthält keine Art von Metadaten, und so müssen wir einig Möglichkeit zu wissen, welche Art von Objekt, das wir reden. [KnownType] stellt diese Informationen nicht zur Verfügung, und es gibt keine klare Möglichkeit, unabhängig einen robusten Schlüssel bereitzustellen.

Eigentlich unterstützt Protobuf keine Vererbung entweder - Protobuf-Net Shims um das durch die Behandlung von Untertypen als verschachtelte Nachrichten. So ein ChildClass1 erscheint tatsächlich im Transit als ob BlahBlahBlah war eine Eigenschaft eines Unterobjekt, ein bisschen wie:

message BaseClass { 
    optional ChildClass1 ChildClass1 = 1; 
    optional SomeOtherSubType SomeOtherSubType = 2; 
} 
message ChildClass1 { 
    optional string BlahBlahBlah = 1; 
} 

etc

Re Weglassen es; In "v2" haben Sie die Möglichkeit, diese Daten außerhalb des Typmodells über Ihren eigenen Code anzugeben. Dies bedeutet, dass Sie nicht alles dekorieren müssen, aber es braucht noch einen Mechanismus, um Schlüssel mit Typen zu verbinden.