POCO（反）序列化在 protobuf-net 中如何工作？
是否可以既不使用 protobuf-net 属性也不显式地将类型添加到模型中来（反）序列化 POCO 类型？
Is it possible to (de)serialize a POCO type using neither protobuf-net attributes nor explicitly adding types into the model?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
目前——简而言之，没有。它需要对您打算如何操作有一个基本了解。我想也许我可以添加一些东西来让您为完全未修饰的类型指定默认策略（不是
DataContract、ProtoContract或 < code>XmlType），但最合适的选项是“所有公共成员”（很像XmlSerializer）。我不想鼓励这样做的原因是它很脆弱。由于 protobuf 规范的定义方式，您得到的只是字段编号。说“好吧，按字母顺序排列并使用它们的位置”很容易，但如果您想更改类型，这是不安全的。让我们面对现实吧，我们都这样做。您可能会惊讶于我添加
AardvarkCount属性的频率，它会打乱字母顺序。因此，我不想让人们轻易陷入数据完整性面临风险的境地。因为我不喜欢别人对我大喊大叫。如果存在全局默认策略，那么很容易在没有意识到的情况下使用该策略，而这正是您开始遇到麻烦的时候。
然而，我确实打算让在每种类型的基础上更容易地选择这些策略（代码都存在，只是不在公共 API 中） - 例如：（
ImplicitFields的东西已经存在，回到 v1 天）或者可能只是：有什么帮助吗？推理有道理吗？
At the moment - in short, no. It needs to have a basic understanding of how you intend it to operate. I guess maybe I could add something to let you specify a default strategy for completely unadorned types (things that aren't
DataContract,ProtoContractorXmlType), but the most appropriate option there would be "all public members" (much likeXmlSerializer).The reason I don't want to encourage this is that it is brittle. Because of how the protobuf spec is defined, all you get is field-numbers. It is easy enough to say "ok, order them alphabetically and use their positions", but that is not safe if you ever want to change the type. And let's face it, we all do. You'd be amazed how often I add an
AardvarkCountproperty, which messes with alphabetical orderings.Hence, I don't want to make it easy to get people into a position where they risk data integrity. Because I don't like people shouting at me. If there was a global default policy, it would be easy to use that policy without realising it, which is when you start getting into trouble.
I do, however, intend making it easier to choose those strategies on a per-type basis (the code all exists, it just isn't in the public API) - for example:
(the
ImplicitFieldsstuff already exists, back to v1 days) or maybe just:any help? does the reasoning make sense?
我对此表示怀疑。属性会使用什么整数 ID？
您当然可以编写一些基于反射的代码，将类型添加到模型中，而无需手动指定配置。但我想当您从类型中添加/删除属性时，您会遇到版本控制问题。因为我认为没有办法隐式创建从字符串到整数的稳定映射。
您可能还可以在 protobuf 中定义一些键值格式，以便可以使用字符串键而不是整数键。但这样你就失去了 protobuf 提供的优势。你可以只使用 json/bson 来代替。
I doubt it. What integer id's would it use for the properties?
You could of course write some reflection based code that adds the types to the model without manually specifying the configuration. But I imagine you'll get versioning problems when you add/remove properties from your types. Since I see no way to create a stable mapping from strings to integers implicitly.
You probably could also define some key-value format inside protobuf so you can use string keys instead of integer keys. But then you lose the advantages protobuf offers. And you could just use json/bson instead.
CodesInChaos 所说的是真的，关于模型更改可能会破坏事物，但对于更简单的项目或模型稳定的情况，您可以有效地做到这一点。操作方法如下： https://github.com/danielcrenna/protobuf-poco
What CodesInChaos is saying is true, about model changes likely breaking things, but for simpler projects or where models are stable, you can do that effectively. Here's how: https://github.com/danielcrenna/protobuf-poco