Сообщение Re: Сериализация Dictionary<string, object> от 01.06.2020 14:46
Изменено 01.06.2020 16:42 VladD2
Re: Сериализация Dictionary<string, object>
Здравствуйте, VladD2, Вы писали:
VD>Всем привет.
VD>Казалось бы, на первый взгляд, простейшая задача. Есть Dictionary<string, object>. Нужно записать его в ветку реестра текущего пользователя и восстановить потом в обратно Dictionary<string, object>. Беда только в том, что в object могут быть разные типы. В том числе целые могут быть разных тпов: int, long, uint... Там могут появляться только примитивные типы или к ним сводимые (строки, целые разных типов, энумы, даты), т.е. типы колонок БД. Вот только важно, чтобы если был long, чтобы они десерелизоваля.
VD>Решил сереализнуть его через Newton json, но он информацию о типах не особо сохраняет, так что при десериализации вместо, скажем, uint или long получаем int, а это не приемлемо.
VD>Добился желаемого только через BinaryFormatter. Но он порождает очень некомпактный выхлоп. Тратить время на зипование тоже не хочется.
VD>Есть какие-то более компактные альтернативы корректно сохраняющие тип значений в object-ах?
Ну, тут либо перебрать имеющиеся бинарные форматы: BSON, CBOR, MessagePack,... но вряд ли они будут отличать int от long, либо за день написать пару своих методов для сериализации/десериализации ограниченного числа типов.
Вопрос задачи и её важности. Ничего плохого в BinaryFormatter и его архивации нет. Если по факту скорость работы будет приемлема, то нечего и велосипеды строить. Те же офисные программы давно уже ушли от бинарных форматов и пришли к упакованным xml, как-то люди с этим живут
VD>Всем привет.
VD>Казалось бы, на первый взгляд, простейшая задача. Есть Dictionary<string, object>. Нужно записать его в ветку реестра текущего пользователя и восстановить потом в обратно Dictionary<string, object>. Беда только в том, что в object могут быть разные типы. В том числе целые могут быть разных тпов: int, long, uint... Там могут появляться только примитивные типы или к ним сводимые (строки, целые разных типов, энумы, даты), т.е. типы колонок БД. Вот только важно, чтобы если был long, чтобы они десерелизоваля.
VD>Решил сереализнуть его через Newton json, но он информацию о типах не особо сохраняет, так что при десериализации вместо, скажем, uint или long получаем int, а это не приемлемо.
VD>Добился желаемого только через BinaryFormatter. Но он порождает очень некомпактный выхлоп. Тратить время на зипование тоже не хочется.
VD>Есть какие-то более компактные альтернативы корректно сохраняющие тип значений в object-ах?
Ну, тут либо перебрать имеющиеся бинарные форматы: BSON, CBOR, MessagePack,... но вряд ли они будут отличать int от long, либо за день написать пару своих методов для сериализации/десериализации ограниченного числа типов.
Вопрос задачи и её важности. Ничего плохого в BinaryFormatter и его архивации нет. Если по факту скорость работы будет приемлема, то нечего и велосипеды строить. Те же офисные программы давно уже ушли от бинарных форматов и пришли к упакованным xml, как-то люди с этим живут
Re: Сериализация Dictionary<string, object>
Здравствуйте, VladD2, Вы писали:
VD>Есть какие-то более компактные альтернативы корректно сохраняющие тип значений в object-ах?
Ну, тут либо перебрать имеющиеся бинарные форматы: BSON, CBOR, MessagePack,... но вряд ли они будут отличать int от long, либо за день написать пару своих методов для сериализации/десериализации ограниченного числа типов.
Вопрос задачи и её важности. Ничего плохого в BinaryFormatter и его архивации нет. Если по факту скорость работы будет приемлема, то нечего и велосипеды строить. Те же офисные программы давно уже ушли от бинарных форматов и пришли к упакованным xml, как-то люди с этим живут
VD>Есть какие-то более компактные альтернативы корректно сохраняющие тип значений в object-ах?
Ну, тут либо перебрать имеющиеся бинарные форматы: BSON, CBOR, MessagePack,... но вряд ли они будут отличать int от long, либо за день написать пару своих методов для сериализации/десериализации ограниченного числа типов.
Вопрос задачи и её важности. Ничего плохого в BinaryFormatter и его архивации нет. Если по факту скорость работы будет приемлема, то нечего и велосипеды строить. Те же офисные программы давно уже ушли от бинарных форматов и пришли к упакованным xml, как-то люди с этим живут