Во-первых, я должен отметить, что выполнение такого большого количества настроек в конструкторах не является хорошей идеей.Если это указывает на ваш реальный код, вы можете пропустить конструкторы во время десериализации ([ProtoContract(SkipConstructor=true)]
).Если это просто иллюстративно, хорошо.
Да, такие вещи, как словари и списки, поддерживаются, однако * непосредственно вложенных списков - нет, так что List<List<...>>
на данный момент не в порядке.Вы, вероятно, сойдете с этим с Dictionary<TKey,List<...>>
, потому что его пара ключ-значение уже действует как обертка посередине.
Повторная рекурсия: protobuf-net имеет поддержку многих сценариев рекурсии, ноэто как расширение к формальной спецификации.Таким образом, вам нужно явно включить его, и обратите внимание: этот сценарий будет нелегко взаимодействовать, поскольку для этого нет формальной спецификации;но: [ProtoMember(n, AsReference=true)]
включает отслеживание объекта для отдельного члена.Обратите внимание, что все места, которые используют этот объект, должны быть помечены как таковые, иначе они будут использовать сериализацию дерева.
Re "почему рекурсия не поддерживается напрямую" - потому что: protobuf (формальная спецификация) ведет себя как большинство сериализаторовздесь и дерево сериализатор.Примечание: такие вещи, как XmlSerializer, JavascriptSerializer и DataContractSerializer (в режиме по умолчанию) являются и древовидными сериализаторами и могут взорваться, если получить рекурсивную структуру.Это нормально.Protobuf-net делает все возможное, чтобы разрешить это в нескольких сценариях, но не может включить его по умолчанию, поскольку для этого потребуется другая структура данных, что противоречит цели кросс-платформенной спецификации данных.
Если я пропустил любой из ваших вопросов, пожалуйста, скажите.