Perché devo usare [ProtoInclude]?

Question

Ho letto molte domande sulla funzione di ereditarietà in protobuf-net. Mi chiedo solo se posso usare [DataContract], [DataMember] allo stesso modo di usare [ProtoContract], [ProtoMember]. Perché non ho potuto usare [KnowType] invece di usare [ProtoInclude]?

Ho sollevato questa domanda perché ho utilizzato [DataContract], [DataMember] per la serializzazione di protobuf-net già. Non è stato necessario aggiungere "Protobuf-net". Ha usato solo "System.Runtime.Serialization".

Ma ... Ora se la mia classe ha bisogno di ereditare da qualche classe, devo aggiungere "Protobuf-net" per l'attributo [ProtoInclude]? per esempio,

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 

finalmente, mi chiedo se ho 100 classe figlia, volontà non guido io pazzo aggiungendo 100 [ProtoInclude] Tag all'interno della classe di base?

Thx in adv per qualsiasi aiuto

vee

Answer 1

EDIT: questo non è più necessario in v2 - è possibile specificarlo in fase di esecuzione, o utilizzare DynamicType.

---

La ragione di ciò è che il formato filo protobuf (ideato da Google) non include alcun tipo di metadati, e quindi abbiamo bisogno qualche modo di sapere che tipo di oggetto di cui stiamo parlando. [KnownType] non fornisce queste informazioni e non esiste un modo chiaro per fornire una chiave affidabile in modo indipendente.

In realtà, protobuf non supporta l'ereditarietà o - shim protobuf-net attorno a ciò trattando i sottotipi come messaggi nidificati. Quindi un ChildClass1 sembra in realtà in transito come se BlahBlahBlah era una proprietà di un sub-oggetto, un po 'come:

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

ecc

Re omettendo esso; in "v2", hai la possibilità di specificare questi dati al di fuori del modello tipo, tramite il tuo codice. Ciò significa che non è necessario decorare tutto, ma è ancora necessario un meccanismo per associare le chiavi ai tipi.