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 回答