Как выбрать между protobuf-csharp-port и protobuf-net

Question

Мне недавно пришлось искать C # портирование библиотеки Protocol Buffers, изначально разработанной Google. И угадайте, что, я нашел два проекта, которыми владеют оба очень известных человека: protobuf-csharp-port , написанный Jon Skeet и protobuf-net, написанный Марк Гравелл . Мой вопрос прост: какой мне выбрать?

Мне очень нравится решение Марка, так как оно мне кажется ближе к C # philisophy (например, вы можете просто добавить атрибуты к свойствам существующего класса) и похоже, что оно может поддерживать встроенные типы .NET, такие как System. Guid.

Я уверен, что оба они действительно великие проекты, но каково ваше мнение?

Answer 1

Я согласен с мнением Джона; если вы кодируете в нескольких средах, то его версия дает вам API, аналогичный другим «базовым» реализациям. Protobuf-net гораздо больше похож на то, как реализовано большинство сериализаторов .NET, поэтому он более знаком (IMO) для разработчиков .NET. И, как замечает Джон, необработанный двоичный вывод должен быть идентичным, так что вы можете повторно реализовать его с другим API, если потребуется позже.

Некоторые пункты по отношению к protobuf-net, которые специфичны для этой реализации:

• работает с существующими типами (не только сгенерированными типами из .proto)
• работает под такими вещами, как WCF и memcached
• может использоваться для реализации ISerializable для существующих типов
• поддерживает методы наследования * и обратного вызова сериализации
• поддерживает общие шаблоны, такие как ShouldSerialize[name]
• работает с существующими декорированными типами (XmlType / XmlElement или DataContract / DataMember) - это означает (например), что модели LINQ-to-SQL сериализуются из коробки (до тех пор, пока в DBML включена сериализация)
• в v2, работает для типов POCO без каких-либо атрибутов
• в v2, работает в .NET 1.1 (не уверен, что это огромная возможность продажи) и в большинстве других фреймворков (включая monotouch - ууу!)
• возможно (еще не реализовано) v2 может поддерживать сериализацию с полным графом * (не только с сериализацией дерева)

(* = эти функции используют 100% действительный двоичный файл protobuf, но его может быть сложно использовать в других языках)

Answer 2

Вы также используете другие языки в своем проекте? Если это так, мой порт C # позволит вам писать одинаковый код на всех платформах. Если нет, то порт Марка, вероятно, более идиоматичен для C #. (Я пытался заставить мой код «чувствовать» себя как нормальный C #, но дизайн явно основан на коде Java для начала, намеренно, чтобы он был знаком тем, кто также использует Java.)

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

Answer 3

Согласно этому сайт проекта GitHub protobuf-csharp-port теперь свернут в основной проект Google Protocol Buffers , поэтому он будет официальной реализацией .NET protobuf 3. Однако, protobuf-net последний раз обновлялся в 2013 году , хотя в GitHub недавно было * 1007 коммитов.

Answer 4

Я только что переключился с protobuf-csharp-port на protobuf-net, потому что:

• protobuf-net - это больше ".net like", то есть дескрипторы для сериализации членов вместо генерации кода.
• Если вы хотите скомпилировать .proto файлы protobuf-csharp-port, вам нужно выполнить двухэтапный процесс, т.е. скомпилировать protoc в .protobin, а затем скомпилировать его с protoGen. Protobuf-net делает это за один шаг.

Answer 5

В моем случае я хочу использовать буферы протокола для замены модели связи на основе xml между клиентом .net и бэкэндом j2ee. Поскольку я уже использую генерацию кода, я пойду к реализации Джона.

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