DataContractSerializer：为什么不删除成员？
我正在阅读 Microsoft 的最佳实践：数据合同版本控制，他们指出：
即使在早期版本中 IsRequired 属性保留为默认属性 false，也不要在更高版本中删除数据成员。
任何人都可以提出任何理由吗？ 他们没有详细说明。 既然他们说在更高版本中添加数据成员是可以的，那么似乎删除也可以——实际上，旧版本会将其视为添加。
我想，区别在于您应该在末尾添加新成员（使用 DataMemberAttribute 上的 Order 属性），而删除的属性可能不会在末尾。 但他们还表示，缺少的成员在加载过程中将保留默认值，因此很明显，缺少的成员是可以的。
我缺少什么？ 如果我废弃了我的产品的某个功能并删除了它附带的 [DataMember] 属性，我会导致什么版本互操作问题（前向兼容性和后向兼容性）？
另外，如果我决定对前向兼容性不感兴趣（即，如果我不关心旧版本打开新文件），那么任何此类问题仍然适用吗？
I was reading Microsoft's Best Practices: Data Contract Versioning, and they state:
Do not remove data members in later versions, even if the IsRequired property was left at its default property of false in prior versions.
Can anyone suggest any reason for this? They don't elaborate. Since they say it's fine to add data members in a later version, it seems that removing would be fine too -- effectively, the older version would see it as an add.
The difference, I suppose, is that you're supposed to add new members at the end (using the Order property on the DataMemberAttribute), whereas the property getting removed would probably not be at the end. But they also say that missing members will be left at their default value during loading, so it's clear that missing members are OK.
What am I missing? What version-interop problems would I cause (both forward-compatibility and backward-compatibility) if I obsoleted a feature of my product and removed the [DataMember] property that goes with it?
Also, if I decided that I wasn't interested in forward-compatibility (i.e., if I wasn't concerned about older versions opening newer files), would any such problems still apply?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
仅仅是因为外部服务使用者可能会提供/使用该数据（它们是在您删除某些成员之前创建的）。 如果您更改了服务方法签名，由于数据成员未知，
DataContractSerializer将无法再识别DataContract。因此，如果您的服务消费者都是已知的，那么您可以轻松地按照自己的意愿操作数据成员，只要您：
Simply because outside service consumers may provide/use that data (they were created before you removed some members). In case you've changed service method signature,
DataContractSerializerwon't be able to recognizeDataContractanymore, because of unknown data members.So if your service consumers are all known, you can easily manipulate data members at your own will as long as you:
一个问题是，即使它在序列化/反序列化期间没有中断，您也可能会丢弃数据 - 这意味着您无法成功地将数据往返回调用方。 即给出简单的方法：
如果调用者向您传递带有额外属性的旧对象，他们可能想要回该值。 您可以使用 扩展启用此功能（单独） data API，但坦率地说，人们很少关心这个。
One issue is that even if it doesn't break during serialization/deserialization, you could be throwing away data - meaning that you can't successfully round-trip data back to the caller. i.e. given the simple method:
If the caller is passing you the old object with the extra property, they might want that value back. You can enable this (separately) with the extension data API, but frankly people rarely bother with this.