Каковы дефициты встроенной основанной на BinaryFormatter сериализации .NET?

Ответ U / KetanChawda-MSFT достаточно хорош, если вы действительно можете изменить веб-сервис, но так как это было вне нашего контроля над этим, нам пришлось сделать что-то еще.

Мы создали отдельный пользовательский соединитель SOAP, только для этого одного метода, через который проходит SOAP.

Соединитель имеет один метод, настроенный следующим образом, с API-интерфейсом WCF по умолчанию:

  1. Url - http: //hostname/Service1.svc/SoapPassThrough
  2. Добавьте два пользовательских заголовка: text / xml Content-Type и имя метода SOAPAction (наш: http://tempuri.org/IService1/methodname где tempuri - пространство имен
  3. Установите для тела значение {} (Пустой объект JSON)

В своем приложении логики вы можете создать переменную, содержащую весь XML для стандартного запроса Soap. Я использовал SOAP UI для создания SOAP запрос и просто вставить в XML из сгенерированного запроса. Эта переменная может использоваться как тело в приложении логики, когда вы используете службу.

Этот ресурс может быть полезен для этого: https: // blogs.msdn.microsoft.com/david_burgs_blog/2018/05/03/friendlier-soap-pass-through-with-logic-app-designer-ux/

Из того, что мы пришли к выводу, это Кажется, что пользовательский соединитель на самом деле отправляет строковый тип данных вместо datetime. Похоже, что сам XML-запрос решает эту проблему.

16
задан Sam Saffron 31 March 2009 в 23:43
поделиться

9 ответов

Если Вы имеете в виду BinaryFormatter:

  • быть основанное на полях, очень нетерпимая версия; измените частные детали реализации, и это повреждается (даже просто изменение его к автоматически реализованному свойству)
  • не является перекрестным совместимым с другими платформами
  • не является очень дружественным к новым полям
  • конкретный блок (метаданные записываются в),
  • конкретный MS/.NET (и возможно конкретная версия.NET)
  • не безопасно от путаницы
  • не особенно быстрый, или маленький вывод
  • не работает над легкими платформами (CF? / Silverlight)
  • имеет угнетающую привычку к получению по запросу в вещах, которые Вы не ожидали (обычно через events)

Я провел много времени в этой области, включая запись (бесплатной) реализации "буферной сериализации" протокола Google API для.NET; protobuf-сеть

Это:

  • меньший вывод и быстрее
  • перекрестный совместимый с другими реализациями
  • расширяемый
  • основанный на контракте
  • безопасная путаница
  • независимый блок
  • открытый зарегистрированный стандарт
  • работы над всеми версиями.NET (протест: не протестированный на Микро Платформе)
  • имеет рычаги для включения ISerializable (для дистанционной работы и т.д.) и WCF
21
ответ дан 30 November 2019 в 21:03
поделиться
2
ответ дан 30 November 2019 в 21:03
поделиться

Не гарантируется, что можно сериализировать объекты назад и вперед между различными Платформами (Скажите 1.0, 1.1, 3.5), или даже различные (Моно) Реализации CLR, снова, XML лучше к этой цели.

1
ответ дан 30 November 2019 в 21:03
поделиться

При изменении объекта, Вы сериализируете, все старые данные Вы сериализировали и сохранили, повреждается. Если Вы сохранили в базе данных или даже XML, легче преобразовать старые данные в новый.

1
ответ дан 30 November 2019 в 21:03
поделиться

Управление версиями данных обрабатывается через атрибуты. Если Вы не волнуетесь по поводу управления версиями затем, это не проблема. Если Вы, это - огромная проблема.

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

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

2
ответ дан 30 November 2019 в 21:03
поделиться

Другая проблема, которая пришла на ум:

Классы XmlSerializer расположены в совершенно другом месте от универсальных средств форматирования времени выполнения. И в то время как они очень похожи на использование, XmlSerializer не реализует интерфейс IFormatter. У Вас не может быть кода, который позволяет Вам просто загружать средство форматирования сериализации или во время выполнения между BinaryFormatter, XmlSerializer или пользовательским средством форматирования, не переходя через некоторые дополнительные обручи.

1
ответ дан 30 November 2019 в 21:03
поделиться

Немного менее очевидный - то, что производительность довольно плоха для Сериализации объекта.

Пример

Время, чтобы сериализировать и десериализовать 100 000 объектов на моей машине:

Time Elapsed 3 ms
Full Serialization Cycle: BinaryFormatter Int[100000]

Time Elapsed 1246 ms
Full Serialization Cycle: BinaryFormatter NumberObject[100000]

Time Elapsed 54 ms
Full Serialization Cycle: Manual NumberObject[100000]

В этом простом примере, сериализирующем объект с единственным Int, поле берет 20x медленнее, чем выполнение его вручную. Предоставленный, в сериализованном потоке существует некоторая информация о типе. Но это едва составляет 20X замедление.

0
ответ дан 30 November 2019 в 21:03
поделиться

Сериализируемые типы должны быть украшены [сериализуемым] атрибутом.

Если Вы имеете в виду переменные в классе, Вы неправы. Общедоступные переменные/свойства автоматически сериализируются

0
ответ дан 30 November 2019 в 21:03
поделиться

Я согласен с последним ответом. Производительность довольно низкая. Недавно моя команда программистов завершила преобразование моделирования из стандартного C ++ в C ++ / CLI. В C ++ у нас был рукописный механизм устойчивости, который работал достаточно хорошо. Мы решили использовать механизм сериализации, а не переписывать старый механизм устойчивости.
Старая симуляция с объемом памяти от 1/2 до 1 гигабайта и большинством объектов, имеющих указатели на другие объекты, и тысячами объектов во время выполнения, сохранится в двоичном файле размером примерно от 10 до 15 мегабайт. менее чем за минуту. Восстановление из файла было сопоставимым.
При использовании одних и тех же файлов данных (работающих параллельно) производительность C ++ / CLI примерно в два раза выше C ++, пока мы не выполним постоянство (сериализацию в новой версии). занимает от 3 до 5 минут, чтение - от 10 до 20.Размер сериализованных файлов примерно в 5 раз больше размера старых файлов. В основном мы видим 19-кратное увеличение времени чтения и 5-кратное увеличение времени записи. Это недопустимо, и мы ищем способы исправить это.

Изучая двоичные файлы, я обнаружил несколько вещей: 1. Тип и данные сборки записываются в виде открытого текста для всех типов. Это неэффективно с точки зрения пространства. 2. Для каждого объекта / экземпляра каждого типа записана раздутая информация о типе / сборке. Одна вещь, которую мы сделали в нашем механизме устойчивости, - это выписали таблицу известных типов. Когда мы обнаружили типы в письменной форме, мы проверили их наличие в этой таблице. Если он не существовал, была создана запись с информацией о типе и присвоенным индексом. Затем мы передали тип infor как целое число. (тип, данные, тип, данные) Этот «трюк» значительно сократит размер. Это может потребовать прохождения данных дважды, однако может быть разработан процесс «на лету», где, помимо добавления их в таблицу, отправка в поток, если мы можем гарантировать порядок повторной обработки из потока. .

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

1
ответ дан 30 November 2019 в 21:03
поделиться
Другие вопросы по тегам:

Похожие вопросы: