C# 大型复杂对象即 Web 服务结果
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/17725/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Large, Complex Objects as a Web Service Result
提问by Rob Cooper
Hello again ladies and gents!
女士们先生们，您好！
OK, following on from my other question on ASP.NET Web Service Results, Proxy Classes and Type Conversion. I've come to a part in my project where I need to get my thinking cap on.
好的，接着我关于ASP.NET Web 服务结果、代理类和类型转换的另一个问题。我已经参与到我的项目中，我需要让我的思维上限。
Basically, we have a large, complex custom object that needs to be returned from a Web Service and consumed in the client application.
基本上，我们有一个大型、复杂的自定义对象，需要从 Web 服务返回并在客户端应用程序中使用。
Now, based on the previous discussion, we know this is going to then take the form of the proxy class(es) as the return type. To overcome this, we need to basically copy the properties from one to the other.
现在，根据前面的讨论，我们知道这将采用代理类的形式作为返回类型。为了克服这一点，我们基本上需要将属性从一个复制到另一个。
In this case, that is something that I would really, really, really!like to avoid!
在这种情况下，这是我真的，真的，真的！喜欢避免！
So, it got me thinking, how else could we do this?
所以，这让我想到，我们还能怎么做？
My current thoughts are to enable the object for complete serialization to XML and then return the XML as a string from the Web Service. We then de-serialize at the client. This will mean a fair bit of attribute decorating, but at least the code at both endpoints will be light, namely by just using the .NET XML Serializer.
我目前的想法是启用对象以完全序列化为 XML，然后从 Web 服务以字符串形式返回 XML。然后我们在客户端反序列化。这将意味着相当多的属性修饰，但至少两个端点的代码都是轻量级的，即仅使用 .NET XML Serializer。
What are your thoughts on this?
你对此有何看法？
采纳答案by Cheekysoft
The .Net XML (de)serialisation is pretty nicely implemented. At first thought, I don't think this is a bad idea at all.
.Net XML（反）序列化实现得非常好。起初，我认为这根本不是一个坏主意。
If the two applications import the same C# class(es) definition(s), then this is a relatively nice way of getting copy-constructor behaviour for free. If the class structure changes, then everything will work when both sides get the new class definition, without needing to make any additional changes on the web-service consumption/construction side.
如果两个应用程序导入相同的 C# 类定义，那么这是一种免费获取复制构造函数行为的相对不错的方法。如果类结构发生变化，那么当双方获得新的类定义时，一切都会正常工作，而无需在 Web 服务消费/构建方面进行任何额外的更改。
There's a slight overhead in marshalling and demarshalling the XML, but that is probably dwarved by the overhead of the remote web service call. .Net XML serialisation is well understood by most programmers and should produce an easy to maintain solution.
编组和解组 XML 的开销很小，但这可能与远程 Web 服务调用的开销相去甚远。.Net XML 序列化为大多数程序员所熟知，应该会产生易于维护的解决方案。
回答by mercutio
I had some great answers on a very similar topic yesterday that might be useful for you:
我昨天在一个非常相似的主题上有一些很好的答案，可能对你有用：
回答by Peter Short
I'm loving JSONfor this kind of thing. I just finished a POC drop-things type portal for my company using jQueryto contact web services with script service enabled. The messages are lightweight and parsing etc is pretty much handled. The jQuery ajaxstuff I read was here (loving it!) : jquery ajax article
我很喜欢JSON这种东西。我刚刚为我的公司完成了一个 POC drop-things 类型的门户，用于jQuery联系启用了脚本服务的 Web 服务。消息是轻量级的，解析等几乎得到了处理。jQuery ajax我读过的东西在这里（喜欢它！）：jquery ajax 文章
回答by Peter Meyer
Rob, in looking at your other question as well as this one, it's sounds like the exact situation we have in our environment. What we've done, however, is move away from ASP.Net web services to WCF web services and in the process solved (for the most part) this problem.
Rob，在查看你的另一个问题和这个问题时，这听起来就像我们在我们的环境中遇到的确切情况。然而，我们所做的是从 ASP.Net Web 服务转移到 WCF Web 服务，并在此过程中（大部分）解决了这个问题。
If there is any chance your web service could be implemented as a WCF web service, this might work for you as well. I should mention, that at the same time, we've maintained backwards compatibility with some client applications that need the "ASP.Net web service style" of implementation by using the WCF basichttp binding for the service transport. The end result is that our "newer" client applications are able to use our real business objects (through referencing an assembly containing only these shared objects) as the return types from the web service calls because they make actual WCF calls.
如果您的 Web 服务有可能实现为 WCF Web 服务，这也可能对您有用。我应该提到，与此同时，我们通过使用 WCF basichttp 绑定进行服务传输，保持了与一些需要“ASP.Net Web 服务风格”实现的客户端应用程序的向后兼容性。最终结果是我们的“较新”客户端应用程序能够使用我们的真实业务对象（通过引用仅包含这些共享对象的程序集）作为 Web 服务调用的返回类型，因为它们进行实际的 WCF 调用。
We do this by not utilizing the auto-generated proxy classes and constructing our own client channel to communicate with the WCF service.
我们通过不使用自动生成的代理类并构建我们自己的客户端通道来与 WCF 服务进行通信来做到这一点。
If you can possibly use WCF, let me know I can post some additional information.
如果您可以使用 WCF，请告诉我我可以发布一些其他信息。
