Прежде всего - я думаю, у вас есть техническая база для разработки отличного сериализатора. Тем не менее, я считаю, что различные аспекты сериализации ProtoBuf настолько непрактичны, что я не вижу себя использующим его в его текущем состоянии.
Позвольте мне пройти отбор -
Во-первых, из-за явной необходимости наличия атрибутов ProtoBuf в классе для сериализации он вызывает зависимость развертывания ProtoBuf; в то время как одна из основных идей, лежащих в основе сериализации, заключается в том, что можно брать те же классы и отключать сериализатор (ы), если / когда это необходимо - это означает, что атрибуты и dll могут быть не нужны для различных развертываний.
2-й выключен - если ProtoBuf по умолчанию не использует рекурсивное дерево наследования, это делает его еще более специфичным для Protobuf - это означает, что в коде больше беспорядка, более специфическая зависимость кода и т. Д. На мой взгляд, это очень очевидный недостаток, как если бы вы получили B из A, то естественно, что свойства A должны быть включены при сериализации B - без специального кода, как показано выше в потоке.
В-третьих, представьте себя, что атрибуты не нужны ... тогда вы также можете представить себя сериализованным из объектов, например. Параметры объекта [] - что ProtoBuf в настоящее время не может сделать. Я предполагаю (не будучи экспертом по сериализации), что это может быть так же просто, как поместить класс и сборку как часть сериализованного объекта для его удаленного разрешения, имея в виду, что там же должна находиться и та же библиотека. Другими словами, возможность сериализации любого типа / иерархии типов без явных атрибутов основана на предположении, что на удаленном компьютере будут существовать одинаковые типы по имени и сборке.
Марк, удачи тебе в реализации.
Gawie