Какой пакет NuGet следует использовать между protobuf-net и google.protobuf для нового основного приложения .net?

Какой пакет NuGet следует использовать между protobuf-net и google.protobuf для нового основного приложения .net?

  • Сначала код, а не контракт.
  • На самом деле это только для C #, но было бы здорово, если бы больше языков могли легко читать формат, но не обязательно. Я бы предпочел производительность переносимости для двоичной сериализации. Я также буду использовать XML или Json для переносимости (что, на мой взгляд, лучше подходит для переносимости, хотя и намного медленнее).

person Eric Ouellet    schedule 14.10.2020    source источник
comment
тот, который лучше соответствует вашим потребностям ... в противном случае этот вопрос полностью основан на мнении и, следовательно, не по теме. кстати: ваше дополнение звучит так, будто вы пытаетесь рекламировать protobuf.   -  person Franz Gleichmann    schedule 14.10.2020
comment
Спасибо за ваш комментарий. Но мой главный вопрос: какой из двух пакетов Nuget? Я только что добавил еще один о производительности для дополнительной информации. Я не согласен с вами в том, что производительность вообще основана на мнении. Я вообще не рекламирую protobuf. Но я уже использую его и обнаружил, что он довольно хорош, намного лучше, чем многие другие варианты.   -  person Eric Ouellet    schedule 14.10.2020
comment
да - ваш вопрос какой, я понял. но если вы не знаете, какие у вас требования и какая из них им подходит - это полностью зависит от вашего мнения. мой совет: просто попробуйте и сравните их. (дополнительно: это может снова рассматриваться как не по теме, поскольку вам нужна рекомендация, какую из (двух) библиотек вам следует использовать.)   -  person Franz Gleichmann    schedule 14.10.2020
comment
да, я понятия не имею об ответе (за исключением того, что он здесь - вы пробовали поисковую систему? ;)). но это не то, почему я проголосовал против. я проголосовал против, потому что ваш вопрос не показывает какие-либо усилия, а ваш вопрос очень субъективен и основан на мнении. если вы заботитесь о производительности, вы можете просто протестировать два решения (или поискать существующие тесты). если у вас есть какие-либо архитектурные ограничения, вы лучше знаете о них. этот вопрос как таковой просто не подходит для SO.   -  person Franz Gleichmann    schedule 14.10.2020
comment
Ответ, который вы мне дали, не отвечает на вопрос. Выступление не о двух реализациях, а о protobuf и конкуренции, для которой, поскольку она давно вышла, должны появиться новые конкуренты. Мой вопрос не связан с моим собственным ограничением, он полностью объективен и касается общих вариантов использования. И да, я всегда стараюсь найти ответы, прежде чем спрашивать. Но я уважаю ваше мнение и очень ценю, что вы нашли время, чтобы объяснить мне.   -  person Eric Ouellet    schedule 14.10.2020
comment
Хорошо, если я могу вмешаться: я написал одну из этих реализаций, и я бы сказал, что основываясь на тексте вопроса, здесь нет возможного объективного ответа. Единственный ответ, который я могу дать, это зависит.   -  person Marc Gravell    schedule 14.10.2020
comment
@MarcGravell От чего зависит? Получу ли я что-то, что может помешать сериализации? Почему так много реализации? Вы только один написали? Не все? Также есть *.Core, но все они поддерживают .net core 3.1.   -  person Eric Ouellet    schedule 14.10.2020
comment
@Eric, если вы имеете в виду protobuf-net.Core, это компонент - часть того же инструментария. Что касается чего — сначала код или сначала контракт? был бы мой первый вопрос. Кроме того, вам нужен идиоматический .NET, который оказывается protobuf, или вам нужен идиоматический protobuf, который оказывается .NET? Также, возможно, было бы полезно работать изначально в VB/F#/etc?. Я мог бы, вероятно, подумать о других, если бы было время   -  person Marc Gravell    schedule 14.10.2020
comment
@MarcGravell, я обновил свой вопрос, чтобы попытаться более подробно рассказать о своих потребностях. Надеюсь, я предоставил достаточно информации. Интересно, как другие люди выбирают, какой пакет использовать?   -  person Eric Ouellet    schedule 14.10.2020
comment
@EricOuellet лично я исследую различия. тогда сравните потом с моими требованиями. потом выбрал лучшее. если нет лучшего, я выбираю тот, который чаще обновляется и имеет большую базу пользователей, так как у него больше шансов на поддержку в будущем. если они похожи в этом отношении, я бросаю монетку.   -  person Franz Gleichmann    schedule 14.10.2020
comment
@FranzGleichmann, я никогда не подбрасываю монетку, когда программирую. Всегда есть причина, по которой я предпочитаю что-то другому. Я предпочитаю спрашивать, а не тратить время на тесты, которые заняли бы много времени и в любом случае могли бы привести меня к неправильному выбору. Я сохраню ваши предложения по выбору, если у меня действительно не будет удовлетворительного ответа. Спасибо.   -  person Eric Ouellet    schedule 14.10.2020
comment
@EricOuellet подбрасывает монету: если два варианта практически равны по всем важным пунктам - это не имеет значения. см. также: парадокс Фредкина.   -  person Franz Gleichmann    schedule 14.10.2020
comment
@MarcGravell, как вы думаете, я один с этим вопросом? Тот самый допрос?   -  person Eric Ouellet    schedule 14.10.2020
comment
Повторное открытие, потому что с правкой я считаю, что это становится объективно ответственным.   -  person Marc Gravell    schedule 15.10.2020


Ответы (1)


С редактированием это становится более ответственным; сначала давайте рассмотрим варианты, показанные здесь, а также реализацию Google , в контексте ограничений вопроса:

  1. Google.Protobuf - эталонная реализация
  • + прочный, надежный, ухоженный
  • - изначально контракт сначала (неуправляемый парсер/генератор), только proto3
  1. protobuf-csharp-port
  • - строго по наследству, это фактически стало Google.Protobuf; не использовать
  1. SilentOrbit/protobuf
  • - в первую очередь заключать договор (управляемый парсер/генератор)
  • (честно говоря, я мало что знаю об этом, поэтому не буду много комментировать за или против)
  1. protobuf-net
  • + сначала код или контракт (дополнительный управляемый парсер/генератор)
  • + сначала код можно использовать на любом языке .NET; Схемы .proto могут быть сгенерированы из кода для использования с любой другой платформой/языком (помечены +, потому что, согласно вопросу, это необязательное условие)
  • + приемлемо в хорошем состоянии (это не моя основная работа, но я стараюсь!)

Так; учитывая, что вопрос гласит:

Сначала код, а не контракт.

Кажется, процесс отбора стал очень простым, и protobuf-net была единственной лошадью в этой гонке. С точки зрения .NET Core: protobuf-net полностью соответствует .NET Core, в том числе оптимизирован для API span и впереди возможности .NET 5 / C# 9.

В качестве примечания: если вы начинаете с нуля, я рекомендую использовать версии protobuf-net v3 и использовать самое высокое значение, определенное в настоящее время CompatibilityLevel

person Marc Gravell    schedule 15.10.2020
comment
Большое спасибо, Марк, за повторное открытие этого вопроса и за отличный ответ. На самом деле, я очень рад получить ваш прямой ответ и надеялся на него. Спасибо также за добавление информации об уровне совместимости. ModuleAttribute является новым для меня. Должен ли я включать его в каждый файл, где класс имеет атрибут ProtoContract. Есть ли способ указать сериализатору использовать 300 напрямую по умолчанию? - person Eric Ouellet; 15.10.2020
comment
@ Эрик, это именно то, что делают [module:CompatibilityLevel(...)] или [assembly:CompatibilityLevel(...)] - они говорят что угодно в этом модуле / сборке: использует X. Я бы рекомендовал модуль (вместо сборки) - в большинстве случаев, когда люди говорят сборка, они на самом деле имеют в виду модуль (просто: большинство сборок имеют только один модуль, отсюда и путаница). Вы также можете прикрепить его к определенным классам с разными уровнями, не используя префикс сборки/модуля. - person Marc Gravell; 15.10.2020
comment
Насколько я могу судить, protobuf-net не поддерживает новый формат JSON. Я понимаю, что JSON противоречит цели использования protobuf, но это фича, и она может быть полезна. Или у меня все не так? - person Dave New; 23.06.2021
comment
@ Дэйв, конечно, но это также куча работы, которую никто не делал, так что... - person Marc Gravell; 24.06.2021