Protobuf-net включает определенный член не сериализуемого базового класса - PullRequest
2 голосов
/ 11 февраля 2012

Мы используем protobuf-net (и нам это нравится!). Теперь у нас есть дочерний класс, оформленный протоконтрактом, полученный из родительского базового класса, который НЕ оформлен в протоконтракте.

Мы пытаемся заставить дочерний класс сериализовать / десериализовать некоторые поля родительского класса.

public abstract class TableServiceEntity
{
    public virtual string PartitionKey { get; set; }
    public virtual string RowKey { get; set; }
    public DateTime Timestamp { get; set; }
}

[ProtoContract]
public class IndicatorStreamIndex : TableServiceEntity
{
    // protomember properties
}

Как мы можем получить IndicatorStreamIndex для сериализации / десериализации PartitionKey, RowKey и Timestamp?

Лучший, Mike

Ответы [ 2 ]

2 голосов
/ 08 октября 2012

Прежде всего - я думаю, у вас есть техническая база для разработки отличного сериализатора. Тем не менее, я считаю, что различные аспекты сериализации ProtoBuf настолько непрактичны, что я не вижу себя использующим его в его текущем состоянии.

Позвольте мне пройти отбор - Во-первых, из-за явной необходимости наличия атрибутов ProtoBuf в классе для сериализации он вызывает зависимость развертывания ProtoBuf; в то время как одна из основных идей, лежащих в основе сериализации, заключается в том, что можно брать те же классы и отключать сериализатор (ы), если / когда это необходимо - это означает, что атрибуты и dll могут быть не нужны для различных развертываний.

2-й выключен - если ProtoBuf по умолчанию не использует рекурсивное дерево наследования, это делает его еще более специфичным для Protobuf - это означает, что в коде больше беспорядка, более специфическая зависимость кода и т. Д. На мой взгляд, это очень очевидный недостаток, как если бы вы получили B из A, то естественно, что свойства A должны быть включены при сериализации B - без специального кода, как показано выше в потоке.

В-третьих, представьте себя, что атрибуты не нужны ... тогда вы также можете представить себя сериализованным из объектов, например. Параметры объекта [] - что ProtoBuf в настоящее время не может сделать. Я предполагаю (не будучи экспертом по сериализации), что это может быть так же просто, как поместить класс и сборку как часть сериализованного объекта для его удаленного разрешения, имея в виду, что там же должна находиться и та же библиотека. Другими словами, возможность сериализации любого типа / иерархии типов без явных атрибутов основана на предположении, что на удаленном компьютере будут существовать одинаковые типы по имени и сборке.

Марк, удачи тебе в реализации.

Gawie

2 голосов
/ 13 февраля 2012

Это можно легко настроить в v2, используя RuntimeTypeModel для настройки конфигурации во время выполнения:

// this should only be done once per AppDomain, usually at app startup
RuntimeTypeModel.Default.Add(typeof (IndicatorStreamIndex), true)
    .Add("PartitionKey", "RowKey", "Timestamp");

// then when needed:
var obj = new IndicatorStreamIndex
{
    RowKey = "abc",
    PartitionKey = "def",
    Timestamp = DateTime.Today
};
var clone = Serializer.DeepClone(obj);
Console.WriteLine(clone.RowKey); // "abc"
Console.WriteLine(clone.PartitionKey); // "def"
Console.WriteLine(clone.Timestamp); // 13/02/2012
...