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

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

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

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

Ответ 1

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

Некоторые точки re protobuf-net, которые относятся к этой реализации:

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

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

Ответ 2

Используете ли вы другие языки в своем проекте? Если это так, мой порт С# позволит вам писать аналогичный код на всех платформах. Если нет, порт Marc, вероятно, более идиоматический С# для начала. (Я пытался сделать свой код "чувствовать себя" как обычный С#, но дизайн явно основан на Java-коде для начала, преднамеренно, чтобы он был знаком с теми, кто использует Java.)

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

Ответ 3

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

Ответ 4

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

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

Ответ 5

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

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