¿Por qué tengo que usar [ProtoInclude]?

Question

He leído muchas preguntas sobre la función de herencia en protobuf-net. Me pregunto si puedo usar [DataContract], [DataMember] de la misma manera que con [ProtoContract], [ProtoMember]. ¿Por qué no pude usar [KnowType] en lugar de usar [ProtoInclude]?

Planteo esta pregunta porque ya utilicé [DataContract], [DataMember] para la serialización de protobuf-net. No fue necesario agregar "Protobuf-net". Solo usó "System.Runtime.Serialization".

Pero ... Ahora, si mi clase necesita heredar de alguna clase, ¿tengo que agregar "Protobuf-net" para el atributo [ProtoInclude]? por ejemplo,

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 

por último, me pregunto si tengo 100 clase hija, ¿No voy a conducir yo loco adición de 100 etiquetas [ProtoInclude] dentro de la clase base?

Thx adv por cualquier ayuda

uve

Answer 1

EDIT: esto ya no es necesario en v2 - se puede especificar esto en tiempo de ejecución, o utilizar DynamicType.

---

La razón de esto es que el formato de alambre protobuf (ideado por Google) no incluye ningún tipo de metadatos, y por lo que necesitamos un poco de forma de saber qué tipo de objeto que estamos hablando. [KnownType] no proporciona esta información, y no hay una forma clara de proporcionar una clave robusta de forma independiente.

En realidad, protobuf no soporta la herencia ya sea - cuñas protobuf-net en torno a que mediante el tratamiento de subtipos como mensajes anidados. Por lo que un ChildClass1 aparece realmente en tránsito BlahBlahBlah como si era una propiedad de un sub-objeto, un poco como:

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

etc

Re omitirla; en "v2", tiene la opción de especificar estos datos fuera del modelo tipo, a través de su propio código. Esto significa que no necesita decorar todo, pero todavía necesita algún mecanismo para asociar claves con tipos.