将 DataMember 添加到 DataContract 的不同命名空间

发布于 2024-08-10 14:04:44 字数 396 浏览 5 评论 0原文

使用 XmlSerializer,我可以让我的成员位于与父类型不同的命名空间中。

我可以使用 DataContractSerializer 做同样的事情吗?

我想要以下 XML:

<h:Type xmlns:h="http://schemas.e.com/WebServices"
    xmlns="http://schemas.e.com/WebServices">
  <Member xmlns="http://schemas.e.com/CoreTypes">0</Member>
</h:Type>

这可以用 DataContractSerializer 实现吗?

With the XmlSerializer I can have my members in different namespaces to the parent type.

Can I do the same thing with DataContractSerializer?

I would like the following XML:

<h:Type xmlns:h="http://schemas.e.com/WebServices"
    xmlns="http://schemas.e.com/WebServices">
  <Member xmlns="http://schemas.e.com/CoreTypes">0</Member>
</h:Type>

Is this possible in with DataContractSerializer?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

于我来说 2024-08-17 14:04:44

您可以在不同的命名空间中定义子数据契约并将它们用作另一个数据契约的成员,但您无法控制各个成员名称和/或形状。 DataContractSerializer 并不是要取代 XmlSerializer 来对 XML“形状”进行细粒度控制。

You can define subdatacontracts in different namespaces and use them as members of another datacontract, but you can't control the individual member names and/or shapes. The DataContractSerializer isn't intended to replace XmlSerializer for fine-grained control of the "shape" of your XML.

夜夜流光相皎洁 2024-08-17 14:04:44

虽然正如 此答案中所述,这是正确的,nitzmahone 特定的数据协定类型不能在多个命名空间中声明成员,因此在类型层次结构中,派生类型可能属于不同的数据协定命名空间它们继承的基本类型。发生这种情况时,每个成员都将被序列化到声明的命名空间中。通过构造适当的类型层次结构,可以通过 DataContractSerializer 对具有不同命名空间中的成员的 XML 实体进行序列化(反序列化)。

具体规则如下:

  1. 其基类型的数据成员始终位于顺序的第一位。1

  2. 数据成员被序列化到数据成员类型的数据协定命名空间中 数据成员被序列化到声明

  3. 数据协定类型的根命名空间是其最派生类型的命名空间。

  4. XML 元素按照 数据会员订单DataContractSerializer 不允许在反序列化期间自由重新排序数据成员。2

  5. 集合有自己的规则,如 数据协定中的集合类型;这个答案不适用于它们。

因此,问题中的 XML 可以由以下类型层次结构中的 DerivedType 使用:

[DataContract(Name = "Base", Namespace = "http://schemas.e.com/CoreTypes")]
public class BaseType
{
    [DataMember]
    public int Member { get; set; }
}

[DataContract(Name = "Type", Namespace = "http://schemas.e.com/WebServices")]
public class DerivedType : BaseType
{
}

并且,一般来说,任何命名空间序列中的任何 XML 元素序列都可以通过应用上述规则来获取构造适当的类型层次结构,提供满足在不同命名空间中反序列化元素的要求的解决方法。

当然,由于其他原因,这样的层次结构可能会不方便,在这种情况下,可以将首选数据模型类型替换为 DTO 通过使用数据合约代理机制。


1 数据成员订单

2 数据成员顺序和 XML 反序列化

While it is true as stated in this answer by nitzmahone that a specific data contract type cannot have declared members in multiple namespaces, it is possible that, in a type hierarchy, derived types can belong to different data contract namespaces than the base types from which they inherit. When this happens, each member will be serialized into the namespace in which it is declared. By constructing an appropriate type hierarchy, XML entities with members in disparate namespaces can be (de)serialized by DataContractSerializer.

The specific rules are as follows:

  1. If a data contract type is a part of an inheritance hierarchy, data members of its base types are always first in the order.1

  2. Data members are serialized into the data contract namespace of the data member type in which they are declared.

  3. The root namespace of a data contract type is the namespace of its most derived type.

  4. XML elements are (de)serialized in the order specified by Data Member Order. DataContractSerializer does not allow for data members to be freely reordered during deserialization.2

  5. Collections have their own rules as specified in Collection Types in Data Contracts; this answer does not apply to them.

Thus the XML in the question can be consumed by DerivedType in the following type hierarchy:

[DataContract(Name = "Base", Namespace = "http://schemas.e.com/CoreTypes")]
public class BaseType
{
    [DataMember]
    public int Member { get; set; }
}

[DataContract(Name = "Type", Namespace = "http://schemas.e.com/WebServices")]
public class DerivedType : BaseType
{
}

And, in general, any sequence of XML elements in any sequence of namespace(s) can be obtained by applying the rules above to construct an appropriate type hierarchy, offering a workaround that meets the requirement of deserializing elements in different namespaces.

Of course, such a hierarchy might be inconvenient for other reasons, in which case the preferred data model types can be replaced with DTOs by using the data contract surrogate mechanism.


1 Data Member Order.

2 Data Member Order and XML Deserialization

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文