protobuf и List ‹object› - как сериализовать / десериализовать?

У меня есть List<object> с объектами разных типов, такими как целые числа, строки и настраиваемые типы. Все пользовательские типы настроены на protobuf. Сейчас я хочу сериализовать / десериализовать этот список с помощью protobuf.net. До сих пор я подозреваю, что мне нужно явно объявлять каждый тип, что, к сожалению, невозможно с этими конструкциями смешанного списка. Поскольку у двоичного форматера нет проблем с этим, я надеюсь, что я что-то упустил, и что вы можете мне помочь. Итак, мой вопрос в том, как работать с объектами в protobuf.net.


person Community    schedule 29.05.2009    source источник
comment
пожалуйста, также скажите мне, сколько данных будет потребляться для сериализации списка, содержащего более 10 000 элементов в качестве примера?   -  person LoveToCode    schedule 23.08.2016


Ответы (2)


(раскрытие: я автор protobuf-net)

BinaryFormatter - сериализатор на основе метаданных; то есть он отправляет информацию типа .NET о каждом сериализованном объекте. protobuf-net - это сериализатор на основе контрактов (двоичный эквивалент XmlSerializer / DataContractSerializer, который также отклонит это).

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


Это не идеально, но работает ... будет легче, когда я завершу работу по поддержке схем времени выполнения:

using System;
using System.Collections.Generic;
using ProtoBuf;
[ProtoContract]
[ProtoInclude(10, typeof(DataItem<int>))]
[ProtoInclude(11, typeof(DataItem<string>))]
[ProtoInclude(12, typeof(DataItem<DateTime>))]
[ProtoInclude(13, typeof(DataItem<Foo>))]
abstract class DataItem {
    public static DataItem<T> Create<T>(T value) {
        return new DataItem<T>(value);
    }
    public object Value {
        get { return ValueImpl; }
        set { ValueImpl = value; }
    }
    protected abstract object ValueImpl {get;set;}
    protected DataItem() { }
}
[ProtoContract]
sealed class DataItem<T> : DataItem {
    public DataItem() { }
    public DataItem(T value) { Value = value; }
    [ProtoMember(1)]
    public new T Value { get; set; }
    protected override object ValueImpl {
        get { return Value; }
        set { Value = (T)value; }
    }
}
[ProtoContract]
public class Foo {
    [ProtoMember(1)]
    public string Bar { get; set; }
    public override string ToString() {
        return "Foo with Bar=" + Bar;
    }
}
static class Program {
    static void Main() {
        var items = new List<DataItem>();
        items.Add(DataItem.Create(12345));
        items.Add(DataItem.Create(DateTime.Today));
        items.Add(DataItem.Create("abcde"));
        items.Add(DataItem.Create(new Foo { Bar = "Marc" }));
        items.Add(DataItem.Create(67890));

        // serialize and deserialize
        var clone = Serializer.DeepClone(items);
        foreach (DataItem item in clone) {
            Console.WriteLine(item.Value);
        }
    }
}
person Marc Gravell    schedule 29.05.2009
comment
Спасибо, Гравелл, на самом деле мне очень нравятся твои работы, и я надеюсь на ответ прямо от тебя. Я знаю, какие типы данных есть в списке, поэтому мне действительно интересно ваше решение. - person ; 29.05.2009
comment
Спасибо, Гравелл, не могли бы вы дать оценку, когда вы закончите поддержку схем времени выполнения? - person ; 29.05.2009
comment
Я бы не; Я давал оценку раньше, и она не подошла ... есть много крайних случаев, которые можно подогнать, даже до, я оптимизирую ее. Если бы мне пришлось угадывать, я полагаю, что если у меня не будет хорошей части свободного времени (чего я не ожидаю), это займет еще пару месяцев. Я также стараюсь обновлять магистраль с учетом последних изменений формата проводов, что делает вещи еще более увлекательными. - person Marc Gravell; 29.05.2009

person    schedule
comment
Это лишний >? - person Robert; 02.06.2015