protobuf-net Наследование и номера полей

Я пытаюсь создать систему сериализации для нашего приложения, которая должна иметь возможность обрабатывать наследование. Еще больше усложняет ситуацию то, что приложение является расширяемым, поэтому маловероятно, что типы будут известны во время компиляции.

Я прочитал предыдущий вопрос stackoverflow, на который был дан ответ, и это помогло мне пройти долгий путь к моей цели. но я наткнулся на камень преткновения, который, вероятно, больше связан с непониманием, чем с какой-либо реальной проблемой!

Итак, это код, который у меня есть сейчас...

public interface IBaseFrame
{

}

public class BasicDataFrame : IBaseFrame
{

}

public class AnotherFrame : BasicDataFrame
{

}

. . . .

RuntimeTypeModel model = TypeModel.Create();
MetaType baseType = model.Add(typeof(IBaseFrame), true);
MetaType basicFrameType = model.Add(typeof(BasicDataFrame),true);

baseType.AddSubType(7, typeof(BasicDataFrame));
model.Add(typeof(AnotherFrame), true);

basicFrameType.AddSubType(8, typeof(AnotherFrame));

Теперь этот код работает правильно (насколько я могу судить!) и все в мире хорошо... Меня беспокоит, где значения 7 и 8 используются в приведенном выше коде для аргумента fieldNumber метода AddSubType.

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

Меня беспокоит, что если плагины перечислены в другом порядке или новые добавлены (или удалены), то автоматически сгенерированный fieldNumber будет отличаться для разных подтипов, что затем вызовет проблемы с обмен файлами журналов между пользователями (у которых могут быть разные плагины и, следовательно, подтипы) или даже файлами в одной системе, когда плагин мог быть удален.

Есть ли какой-нибудь хитрый способ справиться с таким типом наследования автоматически и без проблем с совместимостью в будущем или при изменении плагинов, или мне нужно придумать механизм, при котором эти fieldNumbers могут гарантированно оставаться? contant во всех установках?

Любая помощь или совет, который может быть дан, будет принят с благодарностью!


person Anthony    schedule 14.02.2012    source источник
comment
Только что понял, что я должен был упомянуть, что использую бета-версию версии 2, которая есть на веб-сайте - r480.   -  person Anthony    schedule 14.02.2012


Ответы (1)


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

person Marc Gravell    schedule 14.02.2012
comment
Я так и подозревал! Да ладно.. Хотя приложение можно расширить с помощью механизма плагинов, как правило, кто-то из нашей компании (или доверенная третья сторона) создает плагины, поэтому нам придется реализовать какой-то процесс для выдачи номеров. К счастью, у нас уже есть атрибут, который украшает каждый FrameType и предоставляет некоторые метаданные, мы можем добавить туда fieldNumber — я просто хотел убедиться, что мы не можем использовать магию! Существуют ли какие-либо потенциальные ловушки при использовании больших чисел, которые не являются последовательными? - person Anthony; 14.02.2012