Каковы различия между XmlSerializer и BinaryFormatter

Сериализатор XML создает XML, а также схему XML (неявно). Он будет создавать XML, соответствующий этой схеме.

Одно из следствий состоит в том, что он не будет сериализовать ничего, что не может быть описано в схеме XML. Например, в XML-схеме невозможно различить список и массив, поэтому XML-схему, созданную сериализатором, можно интерпретировать любым способом.

Сериализация во время выполнения (которая BinaryFormatter является частью of) сериализует фактические типы .NET на другую сторону, поэтому, если вы отправите List , другая сторона получит List .

Это очевидно, работает лучше, если на другой стороне работает .NET.

XmlSerializer сериализует тип, считывая все свойства типа, которые имеют как общедоступный метод получения, так и открытый метод установки (а также любые общедоступные поля). В этом смысле XmlSerializer сериализует / десериализует «общедоступное представление» экземпляра.

Модуль форматирования двоичных файлов, напротив, сериализует тип, сериализуя «внутренние элементы» экземпляра, то есть его поля. Любые поля, не отмеченные как [NonSerialized], будут сериализованы в двоичный поток. Сам тип должен быть помечен как [Serializable], как и любые внутренние поля, которые также должны быть сериализованы.

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

Здесь приводится очень полезное сравнение этих двух с точки зрения размера. Это очень важный вопрос, поскольку вы можете отправить свой сериализованный объект на удаленный компьютер.

http://www.nablasoft.com/alkampfer/index.php/2008/10/31/binary-versus-xml-serialization -size /

Просто чтобы взвесить ...

Очевидное различие между ними - «двоичный vs xml», но оно гораздо глубже:

• поля ( BinaryFormatter = bf) vs общедоступные члены (обычно свойства) ( XmlSerializer = xs)
• на основе метаданных типа (bf) и на основе контракта (xs)
• хрупкая версия (bf) vs толерантная к версии (xs)
• "граф" (bf) vs "дерево" (xs)
• специфичный для .NET (bf) vs переносимый (xs)
• непрозрачный ( bf) vs удобочитаемый (xs)

В качестве обсуждения того, почему BinaryFormatter может быть хрупким, см. здесь .

Невозможно обсудить, что больше; все метаданные типа в BinaryFormatter могут увеличить его. А XmlSerializer может очень хорошо работать со сжатием, как gzip.

Однако можно взять сильные стороны каждого; например, Google предоставил открытый исходный код для собственного формата сериализации данных, «буферов протокола». Это:

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

Но, что важно, это очень плотные данные (без метаданных типа, чисто двоичное представление, короткие теги, уловки вроде кодирования с разной длиной по основанию 7) и очень эффективны в обработке (нет сложной XML-структуры, нет строк для сопоставления с членами и т. д.)

Я могу быть немного предвзятым; Я поддерживаю одну из реализаций (включая несколько подходящих для C # /. связаны с любой конкретной реализацией ; формат имеет свои достоинства ;-p