大型、复杂的对象作为 Web 服务结果 [关闭]

Question

女士们先生们，大家好！

好的，接着我的另一个问题 ASP.NET Web 服务结果、代理类和类型转换. 。我的项目已经到了需要进行思考的阶段。

基本上，我们有一个大型、复杂的自定义对象，需要从 Web 服务返回并在客户端应用程序中使用。

现在，根据前面的讨论，我们知道这将采用代理类的形式作为返回类型。为了克服这个问题，我们基本上需要将属性从一个复制到另一个。

在这种情况下，我真的、真的、 真的吗！ 喜欢回避！

所以，这让我想到， 我们还能怎样做呢？

我当前的想法是使对象能够完全序列化为 XML，然后从 Web 服务将 XML 作为字符串返回。然后我们在客户端反序列化。这将意味着相当多的属性装饰，但至少两个端点的代码将很简单，即仅使用 .NET XML 序列化器。

您对此有何看法？

Answer 1

.Net XML（反）序列化实现得非常好。乍一看，我认为这根本不是一个坏主意。

如果两个应用程序导入相同的 C# 类定义，那么这是一种免费获得复制构造函数行为的相对较好的方法。如果类结构发生变化，那么当双方获得新的类定义时，一切都会正常工作，而不需要在 Web 服务消费/构建方面进行任何额外的更改。

编组和解组 XML 的开销很小，但与远程 Web 服务调用的开销相比，这可能显得微不足道。大多数程序员都很好地理解.Net XML 序列化，并且应该产生易于维护的解决方案。

Answer 2

我爱着 JSON 对于这种事情。我刚刚为我的公司完成了一个 POC drop-things 类型的门户网站，使用的是 jQuery 联系启用了脚本服务的 Web 服务。这些消息是轻量级的，并且解析等都已经处理完毕。这 jQuery ajax 我读过的东西在这里（喜欢它！）： jquery ajax 文章

Answer 3

昨天我在一个非常相似的主题上得到了一些很好的答案，可能对您有用：

JavaScript与服务器之间的通信

Answer 4

罗布，看看你的另一个问题和这个问题，这听起来就像我们环境中的情况一样。然而，我们所做的就是从 ASP.Net Web 服务转向 WCF Web 服务，并在此过程中（大部分）解决了这个问题。

如果您的 Web 服务有可能实现为 WCF Web 服务，那么这也可能适合您。我应该提到，与此同时，我们通过使用 WCF basichttp 绑定进行服务传输，保持了与某些需要“ASP.Net Web 服务样式”实现的客户端应用程序的向后兼容性。最终结果是，我们的“较新”客户端应用程序能够使用我们的真实业务对象（通过引用仅包含这些共享对象的程序集）作为 Web 服务调用的返回类型，因为它们进行实际的 WCF 调用。

我们通过不使用自动生成的代理类并构建我们自己的客户端通道来与 WCF 服务进行通信来实现此目的。

如果您可以使用 WCF，请告诉我，我可以发布一些附加信息。