将 DataMember 添加到 DataContract 的不同命名空间
使用 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 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
您可以在不同的命名空间中定义子数据契约并将它们用作另一个数据契约的成员,但您无法控制各个成员名称和/或形状。
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 replaceXmlSerializer
for fine-grained control of the "shape" of your XML.虽然正如 此答案中所述,这是正确的,nitzmahone 特定的数据协定类型不能在多个命名空间中声明成员,因此在类型层次结构中,派生类型可能属于不同的数据协定命名空间它们继承的基本类型。发生这种情况时,每个成员都将被序列化到声明的命名空间中。通过构造适当的类型层次结构,可以通过 DataContractSerializer 对具有不同命名空间中的成员的 XML 实体进行序列化(反序列化)。
具体规则如下:
数据成员被序列化到数据成员类型的数据协定命名空间中 数据成员被序列化到声明
数据协定类型的根命名空间是其最派生类型的命名空间。
XML 元素按照 数据会员订单。
DataContractSerializer
不允许在反序列化期间自由重新排序数据成员。2集合有自己的规则,如 数据协定中的集合类型;这个答案不适用于它们。
因此,问题中的 XML 可以由以下类型层次结构中的
DerivedType
使用:并且,一般来说,任何命名空间序列中的任何 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:
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
Data members are serialized into the data contract namespace of the data member type in which they are declared.
The root namespace of a data contract type is the namespace of its most derived type.
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.2Collections 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: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