XML-HTTP-POST在.NET中的集成

我正在从事一个与外部公司集成的.NET项目。这家公司将通过HTTP POST（原始XML，而不是SOAP）向我们发送XML消息。他们将向我们发送三种不同类型的XML消息，它们都有自己的XSD。这些XSD之间没有继承层次结构，它们基本上都是独立的XML“实体”

现在，我们只是使用一个IHttpHandler.ashx类来处理XML。我们从每个XSD创建了一个类，并使用XmlSerializer将不同的XML消息转换为对象。这并不理想，因为在创建适当的XmlSerializer来处理消息之前，我们需要知道消息的类型。我们目前只查看消息中的根元素名称，以选择要传递给XmlSerializer的类型

---

必须有更好的方法来做到这一点。。。WCF中是否有一些东西可以通过纯XML自动完成这项工作？或者是否有可以动态序列化多个类型的XML序列化程序？还有其他建议吗？

为什么不使用XmlReadMode.Auto将其读入数据集中？然后您就有了一个可以根据需要读取的对象—您可以查看表[0]以查看您拥有的对象。

WCF as RESTful+POX

---

我对XMLSerializer的唯一问题是它非常脆弱。更改XML以获得更多功能，可能会破坏客户端。我认为最好自己解析XML。可能使用Linq XDocument/XElement？

Linq to XML类非常灵活且易于使用。您可以创建一个新的XElement并插入XML字符串

XElement xml = XElement.Parse(receivedXmlString);

工作完成了

---

Anders Heijlsberg在MIX07上就这一点进行了精彩的演讲。你可能会发现这段视频很有用。Linq到XML的时间大约为26分钟。

我将使用XML序列化程序，只是使用的方式比您目前使用的方式更一般

如果消息可以是三种类型中的一种，那么仍然可以使用XML序列化程序自动读取和反序列化-不需要检查第一个元素来区分它们。但它要求您将XSD合并到单个合并XSD中，然后在.NET端生成单个合并的“union”类型。您还可以通过合并生成的类型，然后使用XSD.exe工具从中派生生成的XSD来实现这一点

在我看来，所谓的XML序列化程序的“脆弱性”不是问题。如果您使用依赖于XSD的XML数据绑定技术，XML通常是脆弱的，XML序列化也是如此。脆弱的不是XML序列化本身。模式可能很脆弱。基于模式的方法（包括.NET中的XML序列化）可能很脆弱，如果模式本身没有考虑到进化的话。例如，适当使用xsd:any和xsd:xmlAny、消息版本标记等。好消息是，有很好的指导来设计灵活的模式，可以优雅地发展

---

但是，这一切可能都不是问题，因为模式已经存在。在任何情况下，都不会通过使用XML序列化程序向系统添加“脆性”

当然，这是事实。但他确实说过他使用xsd来创建类。这对我来说意味着xml可能不够复杂，不足以阻止使用数据集。它不会适用于所有XML，但如果它适用于所有XML，则有相当大的优势—排序、易于显示结果等。唯一可以表示可以加载到数据集中的数据的XSD是为表示数据集而创建的XSD。XSD比VisualStudio中的数据集设计器使用的小子集更通用。不一定正确。我有一个应用程序通过运行在Sun机器上的应用程序的套接字向我发送XML，另一个应用程序通过http post从大型机上运行在MVS中的应用程序发送XML。这两个XSD都不是为.Net数据集设计的，而且都能正确读取，多年来每天读取数万次。并不是所有的XML都可以用这种方式读取——例如，IFX xsd远远超出了数据集的能力——但令人惊讶的是，它能处理的数据量有多大。你只要试试看。如果有效，那就好；如果没有，您可以做一些不同的事情。如果可能的话，我将远离XML序列化程序。它不仅“易碎”，还不够通用，并且已经接近使用寿命的终点。我还没有看到XML序列化程序最近出现的很多连接缺陷被回答为“是的，这是一个bug，我们会修复它”。Brittle和Brittle一样。如果您使用适当的xsd:any设计类型，那么客户端或服务器端的XML序列化程序在面对XML更改时将非常健壮。而且“它的使用寿命即将结束”并不准确。XML序列化程序是并且仍然是.NET BCL的一部分，并且继承了相同的支持策略。至少在未来10年内，它将一直存在并得到支持。真的吗？有“支持”和“支持”。