В чем разница между XmlSerializer и BinaryFormatter

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

С другой стороны, сериализатор XML просто сериализует схему и сериализует только общедоступные поля и значения объекта и никакой другой информации о типе, кроме той (например, интерфейсы, которые реализует тип).

Вот хороший пост, .NET Serialization, сравнивающий BinaryFormatter, SoapFormatter и XmlSerializer. Я рекомендую вам взглянуть на следующую таблицу, которая в дополнение к ранее упомянутым сериализаторам включает DataContractSerializer, NetDataContractSerializer и protobuf-net.

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

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

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

Чтобы обсудить, почему BinaryFormatter может быть хрупким, см. здесь.

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

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

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

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

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

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

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

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

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

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

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

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

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

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