Сериализация коллекций AsReference в ProtoBuf-сети - PullRequest
1 голос
/ 12 сентября 2011

Как было упомянуто в предыдущих постах , когда Список объектов (член большего объекта) помечен атрибутом AsReference, его элементы действительно сериализуются / десериализуются как ссылки. тем не мение сам список не сериализуется как ссылка. Такое поведение нарушает целостность графа объекта. В частности, это отличается от того, что делает MS BinaryFormatter. Интересно, откуда берется это ограничение и что нужно сделать, чтобы оно стало дополнительной функцией?

Я оцениваю миграцию огромного приложения ASP.NET с сеансом состояния SQL из BinaryFormatter в сериализацию ProtoBuf-net для повышения производительности. Приложение имеет довольно Сложная модель данных все сохраняется в сеансе, поэтому вышеописанное может стать причиной ошибок. Кстати, вы можете вспомнить другие существенные различия в поведении между BinaryFormmater и ProtoBuf.net?

1 Ответ

2 голосов
/ 12 сентября 2011

«Что бы это заняло» - я просто получаю несколько минут на разработку, реализацию (дважды: время выполнения против метапрограммирования), модульный тест (дважды: время выполнения против MP), регрессионный тест (дважды ... ), документ, развертывание и т. д. Это не огромная вещь

Прагматичный вариант может заключаться в инкапсуляции списка, так что вам не нужно напрямую ссылаться на список - т.е. вместо:

objA                 objB
> theList            > theList

у вас может быть

objA                 objB               listWrapper
> listWrapper        > listWrapper      > theList

это очевидно не значительно удобно, но сегодня будет работать . Однако поддержка этого сценария есть в моей дорожной карте.

Относительно других существенных отличий ... это полностью зависит от модели вашего состояния (и в случае или я рекомендую здесь достаточно простую модель DTO). Но вещи, которые приходят на ум:

  • это может быть другой конструктор (примечание: вы можете отключить использование конструктора в protobuf-net, как вариант)
  • в зависимости от того, как вы помечаете элементы, вы можете работать на уровне свойств (BinaryFormatter - это уровень поля; protobuf-net может также работать на уровне поля, если необходимо)
  • protobuf-net не так сильно поддерживает неожиданные типы (хотя DynamicType является опцией в некоторых сценариях); обычно предпочитает заранее знать, как будут выглядеть данные
  • protobuf-net не сериализует делегаты / события (BinaryFormatter делает)
  • отслеживание ссылок явное (opt-in) в protobuf-net и неявное (автоматическое) в BinaryFormatter
  • и, возможно, несколько других вещей, которые произошли бы, если бы я увидел модель
...