0

我正在尝试使用DataContractSerializer来序列化一个简单的对象：

public class MyType {
  public string MyValue { get; set; }
}

我进行了广泛的研究并发现，根据 MSDN，与普遍的看法相反，该属性[DataContract]是可选的，如果没有在类上指定任何属性，则所有公共读/写属性和字段都会被序列化。事实上，当我这样序列化它时 - 它按预期工作。

现在，如果我还在[Serializable]类上添加一个属性，我会得到一个不同的序列化，它包含臭名昭著的前缀“k__BackingField”（因为我的属性是一个自动属性）。

我的问题：

  1. 谁能解释为什么DataContractSerializer 在有和没有 [Serializable] 属性的情况下会有不同的行为？不是技术解释（可能类似于“在这种情况下 XmlObjectSerializer 的基类正在接管”），而是设计原因。我看不出这种不同的序列化有何用处。如果有的话 - 它会破坏向后兼容性。建议改变微软有意义吗？
  2. 如果我不想检查整个庞大的数据模型并用 [DataContract] 和 [DataMember] 装饰所有内容 - 是否有更通用的方法来告诉 DataContractSerializer 或 WCF 基础架构（通过服务合同属性等） ，以序列化在其默认（读取：未修饰）行为中标记为 [Serializable] 的类？不幸的是，属性 [XmlSerializerFormat] 对我来说不是一个选项，我需要坚持使用 WCF 的 DataContractSerializer。
4

1 回答 1

-1

对于您的第一个问题：该[Serializable]属性适用于 .NET Remoting 传输，该传输带有其旧版兼容性序列化。因此，不鼓励在使用 WCF 时应用此属性。您可以在此处阅读有关此内容的更多信息。

您的第二个问题，如果没有更多细节，不容易回答。一个简单的解决方法是将[System.Xml.Serialization.XmlRoot()]属性应用于您的数据模型类。虽然此属性不适用于 Web 服务，但它确实提供了同样忽略私有属性的干净 SOAP 消息。互操作性可能是一个问题，我没有对此进行测试。

更好的解决方法是真正使用[DataContract]. 这使您可以更好地控制通过网络发送的数据。在我看来，通过服务发送大量数据模型是一种代码味道。我会尽可能尝试将它们重构为更小的类。

于 2013-10-14T09:27:02.193 回答