Почему я должен использовать [ProtoInclude]?

Question

Почему я должен использовать [ProtoInclude]?

Я считал много вопросов о функции наследования в protobuf-сети. Я просто задаюсь вопросом это, если я могу использовать [DataContract], [DataMember] таким же образом использования [ProtoContract], [ProtoMember]. Почему я не мог использовать [KnowType] вместо того, чтобы использовать [ProtoInclude]?

Я поднимаю этот вопрос, потому что я уже использовал [DataContract], [DataMember] для сериализации protobuf-сети. Не было никакой потребности добавить "Protobuf-сеть". Это использовало только "Систему. Время выполнения. Сериализация".

Но... Теперь, если мой класс должен наследоваться некоторому классу, я должен добавить "Protobuf-сеть" для [ProtoInclude] атрибут? например,

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

наконец, интересно, есть ли у меня 100 дочерних классов, Разве я не буду управлять мной сумасшедшее добавление 100 [ProtoInclude] теги в базовом классе?

Спасибо в рекламе для любой справки

vee

5

protobuf-net

задан tong 23 June 2010 в 08:51

1 ответ

Другие вопросы по тегам:

protobuf-net

Похожие вопросы:

score 4 · Accepted Answer

EDIT: это больше не требуется в v2 - вы можете указать это во время выполнения, или использовать DynamicType.

Причина в том, что формат передачи данных protobuf (разработанный Google) не содержит метаданных типа, поэтому нам нужен какой-то способ узнать, о каком типе объекта идет речь. [KnownType] не предоставляет такой информации, и нет четкого способа обеспечить надежный ключ независимо.

На самом деле, protobuf не поддерживает наследование также - protobuf-net обходит это, рассматривая подтипы как вложенные сообщения. Поэтому ChildClass1 фактически появляется в транзите, как будто BlahBlahBlah было свойством подобъекта, немного похоже на:

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

etc

Опустим это; в "v2" у вас есть возможность указать эти данные вне модели типов, через ваш собственный код. Это означает, что вам не нужно украшать все, но все равно нужен какой-то механизм для связывания ключей с типами.