我需要开发一个Web服务，该服务将通过SOAP 向Java客户端公开。我们有一个定义良好的模式，用于在两个系统之间进行通信。现在，我需要在我的 WCF 协定上公开一个操作，该操作采用架构对象并将其存储在我们的数据库中。
我遵循以下内容来开发网络服务。
- 在 wcf 中通过 basichttp 托管它
- 使用 xsd 创建架构的对象模型.exe
- 将架构作为操作的参数，类似于 DoThis（SchemaObject schema）
由于这将在 WCF 中公开，因此我修改了 xsd 工具生成的对象模型。我们的模式具有多个嵌套级别，并且是链接在一起的 4 个不同模式的组合。xsd 工具生成的对象图具有抽象类、继承等。
为了做到这一点，我已经在每个类上定义了DataContract attrbute，并将命名空间添加到其中，该命名空间已经在XmlTypeAttribute中存在。此外，我还向每个属性添加了 DataMemebers。
架构中的某些属性是工具使用 xmlarrayitem 属性定义的数组。
现在，当我使用 SOAP UI 发送请求时，对象没有按预期进行反序列化。几乎所有字段都显示为 null，它具有某种继承层次结构。我已经将 KnownType 属性添加到相应的数据协定中，但仍然不起作用。
我的问题是：
-
这是开发 Web 服务的正确方法吗？
-
有没有办法避免放置数据协定和数据成员，而只使用 xsd 工具添加的序列化属性？
-
是否有必要使用数据合同属性，它是否不适用于 xmlserialization 属性，因为它在 xml 反序列化的情况下有效？
WCF 支持两种类型的序列化 - DataContractSerializer 和 XmlSerializer 。
XSD.exe 生成具有所有必需XmlSerializer属性的强类型实体。无需添加任何DataContract或DataMemeber属性即可在 WCF 中使用生成的类。
有关更多详细信息，请参阅 MSDN - http://msdn.microsoft.com/en-us/library/ms733901.aspx
还要非常小心 xsd.exe 生成的实体。正如您可能已经看到的那样，WCF 服务器将吃掉您可以在这些文件中进行的许多序列化更改，但这对于客户端来说将是重大更改，因为它们在 XSD 上中继。
如果可能的话，我将保留这些自动生成的实体而不进行更改，以保证界面不会损坏。您可以引入单独的 DTO 类以在业务层中使用。您可以在那里实现继承层次结构。
如果您觉得需要更改自动生成的类，一堆单元测试会有所帮助。这些测试用例应生成不同的数据集，将它们序列化为 XML，并通过 XSD 检查该 XML。
从技术上讲，我没有看到您实现服务的方式有任何特别的缺陷。
但从建筑的角度来看，这对我来说太复杂了。发送"扁平"数据结构并将复杂性隐藏在其他地方总是更容易。我建议以下步骤
- 开发一些特殊的"运输"方案，最大限度地使其扁平化。当您的模型更改时，它可以更轻松地更改服务。而且，生成和应对xsd的痛苦也减少了。
- 在通道两侧对特殊转换器进行编码，以将普通模型转换为"平坦"模型，反之亦然。