Сериализация графа двоичных объектов

Question

Я ищу совет по сериализации в приложении .net.Приложение является настольным / толстым клиентским приложением, а сериализация представляет собой постоянный формат документа.Требования к сериализатору:

• Необходимо разрешить сериализацию полей, а не только общедоступных свойств.
• Не должно требовать конструкторов без параметров.
• Необходимо обрабатывать общие графы объектов, т.е.не только DAG, но и общие / двунаправленные ссылки.
• Должен работать с классами фреймворка (например, словари Serialize).

В настоящее время мы используем BinaryFormatter, который довольно хорошо обрабатывает все вышеперечисленное, ноРазмер / производительность и версия допуска является проблемой.Мы используем атрибуты [OnDeserialized / ing] для обеспечения совместимости, но он не допускает больших рефакторингов (скажем, изменение пространства имен) без сложного использования суррогатов и т. Д.

Идеальным решением было бы отбрасываниевместо BinaryFormatter, который работает с нашими существующими аннотациями [NonSerialized] и т. д., но работает лучше и создает формат, который меньше и проще в обслуживании.

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

Итак, вопросы:

• Существуют ли какие-либо "альтернативные" двоичные средства форматирования, которые обеспечивают хорошо документированный формат, работают лучше?
• Подходят ли когда-нибудь буферы протокола длясохраняются большие графы общих объектов, включая типы каркасов?

Answer 1

Буферы протокола в формате не имеет официальной поддержки графов объектов, но protobuf-net предоставляет и отвечает вашим другим требованиям.Чтобы поочередно набирать очки:

• Необходимо разрешить сериализацию полей, а не только открытых свойств

Конечно;protobuf-net может сделать это как для открытых, так и для закрытых полей;расскажите о полях во время выполнения или через атрибуты

• Не должны требовать конструкторов без параметров.

Это доступно в "v2" - опять же, вы можете сказать этопропустить конструктор во время выполнения или с помощью атрибутов (SkipConstructor=true в контракте)

• Должен обрабатывать общие графы объектов, т. е. не только DAG, но и общие / двунаправленные ссылки.

Конечно;отметьте AsReference=true на элементе

• Должен работать с классами каркаса (например, Сериализировать словари).

Стандартные списки и словари работают нормально; однако , у меня есть невыполненный запрос на изменение для поддержки AsReference внутри словаря.Это означает, что Dictionary<string, Foo> не будет в настоящее время запускать код графика для Foo, но я, вероятно, могу найти несколько моментов, чтобы посмотреть на это, если это причиняет вам значительную боль

• Мы используем атрибуты [OnDeserialized / ing] для обеспечения совместимости

Полностью поддерживаются обратные вызовы сериализации

• , но это не допускает больших рефакторингов (скажем, изменение пространства имен) без комплексного использования суррогатов и т. д.

Пространства имен и т. д. совсем не интересны для protobuf-net (если вы не используете опции DynamicType)

• это все равно будет означать необходимость добавления конструкторов без параметров и аннотаций protobuf ко всем классам

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

Answer 2

Попробуйте db4o , это не совсем сериализатор, но, насколько я могу судить, он соответствует вашим требованиям (сложные типы, глубокий граф, наследование?, Словари и т. Д.), Вам не нужно ничего менять на ваших объектах, и API чрезвычайно прост в использовании.

Поддерживает управление версиями / слияние схем.