Для каких сценариев не подходит protobuf-net?

Question

Мы использовали BinarySerialization с нашим приложением C #, но размер и сложность классов, которые необходимо сериализовать, приводит к sloooooow (de) сериализации и большим файлам.

Мы подозреваем, что нам следует написать свои собственные сериализаторы; но protobuf-net заявляет о значительных преимуществах в скорости и размере по сравнению со стандартной двоичной сериализацией .Net, и его может быть проще добавить в наше приложение, чем большое количество индивидуальных сериализаторов.

Прежде чем тратить значительное время и усилия на то, чтобы заставить его работать на нас, я хотел бы знать, есть ли какие-либо нарушители соглашения. Мы используем свойства, определенные с помощью интерфейсов, общих списков абстрактных подклассов, пользовательских перечислений битовых флагов и т. Д. И т. Д. И т. Д. Что остановит работу protobuf-net у нас?

Answer 1

protobuf-net делает все возможное, чтобы придерживаться основной спецификации protobuf, а затем и некоторых (например, с наследованием):

• v1 не очень хорошо работает на основе интерфейсасвойства (т.е. ICustomer и т. д.);Я работаю над улучшением этого в v2
• v1 нравится, что в v2 есть конструктор без параметров (это требование снято в v2)
• вам нужно сказать ему, как сопоставить модель с полями;в v1 это должно быть оформлено на типе (или - это опция для вывода некоторых вещей из имен и т. д.);в v2 это можно сделать внешне
• в v1, перечисления флагов - это боль;в v2 есть возможность передавать сквозные перечисления как необработанные целые числа, что делает его намного более подходящим для кратких резюме
• и наследования, но вы должны быть в состоянии определить все конкретныетипы заранее (чтобы отобразить их целочисленными ключами)
• Обобщения должны быть в порядке
• зубчатые массивы / вложенные списки без промежуточные типы не подходят - вы можете подбиратьэто путем введения промежуточного типа в середине
• не все основные типы имеют встроенную поддержку (например, новые типы смещения даты / времени);в "v2" вы можете ввести свои собственные прокладки для этого при необходимости
• это сериализатор tree , а не сериализатор graph ;У меня есть кое-какие мысли, но пока ничего не реализовано

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

Answer 2

Пожалуйста, прочитайте это здесь в блоге о protobuf-net, чтобы процитировать

What’s the catch?

In the most part, that’s it. WCF will use protobuf-net for any suitable 
objects (data-contracts etc). Note that this is a coarser brush than the 
per-operation control, though (you could always split the interface into 
different endpoints, of course).

Also, protobuf-net does have some subtle differences (especially regarding empty 
objects), so run your unit tests etc.

Note that it only works on the full-fat WCF; it won’t help Silverlight etc, since 
it lacks the extension features – but that isn’t new here.

Finally, the resolver in WCF is a pain, and AFAIK wants the full assembly details 
including version number; so one more thing to maintain when you get new versions. 
If anyone knows how to get around this?

Answer 3

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