C# WCF：接受xml的单个方法或通用ProcessMessage方法

我的公司正在开发一个应用程序，通过TCP套接字和xml消息从另一家公司接收数据。这将传送到单个网关应用程序，然后将其广播到组织中不同机器上相同内部应用程序的多个副本

WCF被选为处理内部通信（内部双向）的技术。开发人员考虑了两种方法

由 WCF服务适用于每种不同的 网关接收到的消息 应用大门 应用程序将解析传入的 外部消息并调用 适当的WCF服务方法。这个 传入的XML将被翻译 进入数据合同DTO并提供 作为相应WCF的参数 方法

内部应用 公开了一个WCF服务，其中包含一个 方法“ProcessMessage”，其中 接受Xml字符串消息作为 论点内部应用程序将 解析然后反序列化接收到的 xml，并对其进行相应的处理

首席开发人员认为选项2是更好的选项，因为它“更容易”序列化/反序列化xml。我认为这个论点没有意义，因为数据契约是由WCF序列化和反序列化的，通过使用WCF，我们最好键入数据。在选项2中，有人可以调用WCF服务并传入任何字符串。我相信选项1提供了一个更整洁的界面，使应用程序更易于维护和使用

这两个选项在某些时候仍然需要对原始xml字符串进行解析和验证，因此，建议在何处执行此验证也可能是一个问题

---

我想知道目前传递这种信息的想法是什么，人们对这两种选择的看法是什么

我希望我正确理解这一点。我认为让你的网关应用程序处理所有的反序列化，让你的内部应用程序公开使用实际DataContract对象的WCF服务可能是有意义的

这样，基于TCP的XML的反序列化在网关上更加集中，内部应用不需要担心，它们只需要公开任何有意义的WCF服务，并且可以处理实际对象

如果您强制内部应用程序进行反序列化，那么如果格式发生更改或其他情况，您可能会得到更多的维护

---

所以我想我会说选项1（除非我误解了）。

如果您可以确保客户端总是向服务器发送数据契约的序列化表示，那么选项1是合适的

但是，如果您需要序列化/反序列化逻辑中的一些灵活性，并且不需要与DataContract紧密耦合，那么选项2看起来不错。当您希望支持xml的其他形式（例如Atom表示、自定义格式的原始xml等）时，特别有用

同样在ProcessMessage（）方法的选项2中，您可以选择决定是否对传入的xml负载进行反序列化（基于请求头或特定于应用程序的内容）

---

在选项1中，WCF运行时将始终对有效负载进行反序列化。

我最近就这方面问了几个问题：和。你会发现这些问题的答案很有趣

对于我们的特定问题，我们决定采用hybrod方法，界面如下所示：

// Just using fields for simplicity and no attributes shown.
interface WCFDataContract
{
    // Header details
    public int id;
    public int version;
    public DateTime writeDateTime;

    public string xmlBlob;

    // Footer details
    public int anotherBitOfInformation;
    public string andSoemMoreInfo;
    public book andABooleanJustInCase;

}

<>我们之所以使用XMLBROB是因为我们拥有页眉和页脚模式，而不是中间的BLB。此外，我们实际上不必处理该blob，而是将其传递给另一个库（由另一个部门创建）。另一个库返回更多的强类型数据

---

祝你好运——我从经验中知道，你的选择2可能很有诱惑力，有时很难反驳，除非你被指责过于单纯，不够务实；）

你理解对了：）这和我得出的结论是一样的。内部应该公开真实的服务，网关应该处理反序列化和广播/路由。感谢这些链接。非常感谢：）