Как работает сериализация POCO (de) в protobuf-net?

Question

Можно ли (де) сериализовать тип POCO, не используя ни атрибуты protobuf-net, ни явное добавление типов в модель?

Answer 1

Я сомневаюсь в этом. Какие целочисленные идентификаторы будут использоваться для свойств?

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

Вы, вероятно, могли бы также определить некоторый формат значения ключа внутри protobuf, чтобы вы могли использовать строковые ключи вместо целочисленных ключей. Но тогда вы теряете преимущества, которые предлагает protobuf. И вы можете просто использовать вместо этого json / bson.

Answer 2

На данный момент - короче, нет.Он должен иметь базовое понимание того, как вы собираетесь его работать.Я думаю, может быть, я мог бы добавить что-то, чтобы позволить указать стратегию по умолчанию для полностью неукрашенных типов (вещи, которые не DataContract, ProtoContract или XmlType), но наиболее подходящая опция тамбыть "всеми публичными членами" (очень похоже на XmlSerializer).

Причина, по которой я не хочу это поощрять, заключается в том, что она хрупкая.Из-за того, как спецификация protobuf определена, все, что вы получаете, это числа полей.Достаточно легко сказать «хорошо, упорядочить их по алфавиту и использовать их позиции», но это небезопасно, если вы когда-нибудь захотите изменить тип.И давайте посмотрим правде в глаза, мы все делаем.Вы будете удивлены тем, как часто я добавляю свойство AardvarkCount, которое портится в алфавитном порядке.

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

Однако я намерен сделать ее прощевыбрать эти стратегии для каждого типа (код все существует, его просто нет в общедоступном API) - например:

model.Add(typeof(MyCrazyType), false).ApplyPolicy(ImplicitFields.AllPublic);

(материал ImplicitFields уже существует, вернемся кv1 дней) или, может быть, просто:

model.Add(typeof(MyCrazyType), ImplicitFields.AllPublic);

любая помощь?имеет ли смысл рассуждение?

Answer 3

То, что CodesInChaos говорит о том, что изменения в моделях могут привести к поломке, но для более простых проектов или с устойчивыми моделями вы можете сделать это эффективно. Вот как: https://github.com/danielcrenna/protobuf-poco