Следует ли мне по-прежнему использовать BinaryFormatter для простой сериализации в .NET 4.0?

Я разрабатываю приложение в стиле "ведущий-ведомый". Главное приложение будет отправлять данные состояния подчиненным (-ым) для обработки и отображения с некоторой постоянной скоростью. Данные состояния упакованы в один класс, содержащий множество полей. Эти типы полей состоят из примитивов, классов, интерфейсов, списков интерфейсов и так далее. Все типы являются либо BCL, либо пользовательскими типами, поэтому пользовательские типы могут быть изменены при необходимости. И главное, и подчиненное приложения будут .NET 4.0. Меня не интересует управление версиями сериализации, поскольку главное и ведомое приложения будут поставляться в паре.

Мне нужен «быстрый» способ сериализации данных состояния на ведущем устройстве и десериализации их на ведомых устройствах. Когда я говорю «быстро», я больше говорю о времени разработки (но время обработки могло быть фактором, если решение было ужасным). Однако ведущее и ведомое устройства будут распределены по глобальной сети, так что некоторый уровень компактности тоже будет неплохим.

В качестве быстрого решения я сейчас подумываю просто использовать BinaryFormatter, а затем сжать поток с помощью GZipStream. Это путь для .NET 4.0?


.net c# performance serialization binary-serialization
person dewald    schedule 12.03.2011    source источник
comment
BinaryFormatter в порядке, нет необходимости таскать стороннее решение для ваших нужд, и его очень просто использовать. Не используйте GZipStream, он только добавляет накладные расходы. Пропускная способность памяти слишком высока, чтобы позволить ей окупиться.   -  person Hans Passant    schedule 12.03.2011
comment
@Hans: Он говорит об отправке данных по WAN (что, вероятно, означает пропускную способность менее 10 Мбит / с). Я думаю, что GZipStream почти обязателен для этого приложения.   -  person Gabe    schedule 12.03.2011

Ответы (2)


arrow_upward
5
arrow_downward

Если скорость разработки является ключевым моментом (особенно если у вас есть интерфейсы и т. Д., Которые вам нужно соответствующим образом настроить для некоторых сериализаторов), тогда, возможно. Просто не забудьте отмечать любые события как:

[field:NonSerialized]

По всем остальным параметрам (производительность ЦП, пропускная способность, надежность в зависимости от версии, совместимость, стоимость обслуживания и т. Д.) Я бы выбрал другие форматы :)

Вот подборка профилей:

Тесты производительности сериализаций, используемых привязками WCF

Возможно, это не удивительно (раз уж я это написал), но я склоняюсь к protobuf-net ...

person Marc Gravell    schedule 12.03.2011
comment
Отличный момент для обозначения событий знаком [NonSerialized]. Я не думал об этом. - person dewald; 12.03.2011
comment
Тесты производительности protobuf-net очень впечатляют. Подойдет ли ваша библиотека для моего дела? Мне нужно сериализовать интерфейсы и списки интерфейсов. Некоторые из этих интерфейсов представляют собой неизменяемые объекты; т.е. у них есть только свойства геттера, а у классов реализации есть частные сеттеры. - person dewald; 13.03.2011
comment
@dewald еще неделю назад боролся с этим; на прошлых выходных я добавил функцию, которая позволит это сделать, сохранив детали базового типа - уродливый ответ на очень распространенный запрос. Смотрите мой блог, чтобы узнать больше. - person Marc Gravell; 13.03.2011

arrow_upward
2
arrow_downward

Взгляните на буферы протоколов здесь: Быстрая и компактная сериализация объектов в .NET

person Nariman    schedule 12.03.2011