Байтовая сериализация

Question

Недавно я обсуждал с коллегой сериализацию байтовых данных по сети. Он использовал класс BinaryFormatter для «разборки» байтовых данных, которые я ему отправлял. Это не сработало, и у него, очевидно, были исключительные ... исключения. Binaryformatter не удалось правильно "разобрать" данные, так как мои данные были просто байтовым массивом.

Его мотивом для BinaryFormatter была независимость от платформы. Я не убежден в такой позиции. Когда мы оба использовали BinaryReader или BinaryWriter, все хорошо работало в коде.

Какая польза от BinaryFormatter, и стоит ли мне использовать его в каждом сценарии, куда бы я ни направлял байты по проводам?

Answer 1

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

К счастью, в .NET есть версии, такие как protobuf-net .

(раскрытие: я автор, но это бесплатно; я не пытаюсь вам что-либо продать - просто сэкономит вам много времени и усилий)

BinaryFormatter очень ... хрупкий; он специфичен для .NET и имеет относительно плохую устойчивость к версиям. Единственный раз, когда я использую его, это негласно для связи между AppDomain с на одной машине. В противном случае я бы посмотрел на сериализаторы на основе контракта, такие как XmlSerializer, DataContractSerializer или protobuf-net.

Answer 2

Определенно, если у вас есть данные как byte[], BinaryFormatter не является разумной вещью для использования. Вы просто записываете данные в провод. Однако, если у вас есть набор объектов и вы хотите сериализовать их в поток, BinaryFormatter гораздо проще использовать, чем вручную писать каждое поле каждого типа вручную. Цель BinaryFormatter или любой схемы сериализатора / десериализатора в целом состоит в том, чтобы обеспечить способ сохранения графа объекта (возможно, сложного) в виде последовательности байтов.