我应该直接绑定到从 web 服务返回的对象吗？答案

【问题标题】：Should I bind directly to objects returned from a webservice?我应该直接绑定到从 web 服务返回的对象吗？
【发布时间】：2010-09-11 17:01:55
【问题描述】：

我应该直接绑定到从 Web 服务返回的对象，还是应该将客户端对象绑定到我的网格控件？例如，如果我有一个返回对象 Car 的服务，我是否应该有一个客户端 Car 对象，我用来自 web 服务 Car 对象的值填充？什么被认为是最佳实践？在 C# 中，我是否需要将我的类标记为可序列化或对它们做一些特别的事情？

【问题讨论】：

标签： c# web-services data-binding serialization

【解决方案1】：

如果您是 Web 服务和客户端的所有者。
而且您需要 Web 服务调用的参数是复杂的类，其中不仅包含数据，还包含行为（实际的编码逻辑），那么在使用 Web 服务框架开发这些 Web 服务时，您会有点麻烦。
正如answer by Rob Cooper 中所建议的，您可以使用纯 xml 作为 Web 服务参数和 xml 序列化，但是有一个更简洁的解决方案。
如果您使用的是 Visual Studio 2005（可能对 2008 应用相同），您可以自定义 VS 创建代理的方式，如本文所述： Customizing generated Web Service proxies in Visual Studio 2005

这样你可以告诉 VS 使用你自己的类而不是生成代理类。

好吧，当我想到它时，它与 Rob Cooper 提出的 solution 几乎相同，只是稍有不同，您不会自己编写 Facade 层，而是将 VS 本身用作该层。

【讨论】：

【解决方案2】：

这是一个很好的问题，与我问自己的两个问题的思路相同：

这两本书对你来说可能都值得一读。

这是我的两点：

尽可能将 Web 服务的返回类型保留为原语。这不仅有助于减小消息的大小，还可以降低接收端的复杂性。
如果您确实需要返回复杂对象，请将它们作为 原始 xml 字符串返回（我将在下面解释）。

然后我要做的是创建一个单独的类来表示对象并处理它的 xml。我确保可以轻松地将类实例化并序列化为 xml。然后两个项目（Web 服务和客户端）都可以引用包含具体对象的 DLL，但没有与代理类的烦人耦合。如果您有共享代码，这种耦合会导致问题。

例如（使用您的 Car 类）：

Web Service (CarFactory) 方法 BuyCar(string make, string model) 是返回汽车的工厂方法。
您还编写了一个处理Car 对象的Mechanic 类来修复它们，这是在不了解Web 服务的情况下开发的。
然后为您的应用程序设置一个Garage 类。您添加对CarFactory 服务的网络引用以获取您的汽车，然后将一些Mechanic 添加到您的车库，然后敲响您的指关节，准备从工厂获取一些汽车以使其工作。
然后一切都崩溃了，当你得到CarFactory.BuyCar("Audi", "R8")的结果然后告诉你的Mechanic.Inspect(myAudi)编译器呻吟，因为Car实际上是CarFactory.Car类型而不是原来的Car类型，是的?

所以，使用我建议的方法：

在自己的 DLL 中创建您的 Car 类。添加方法来实例化它并分别从 XML 序列化它。
创建您的 CarFactory Web 服务，添加对 DLL 的引用，像以前一样构建您的汽车，但不是返回对象，而是返回 XML。
创建您的Garage，添加对Mechanic、Car DLL 和CarFactory Web 服务的引用。调用您的BuyCar 方法，现在它返回一个字符串，然后您将该字符串传递给Car 类，该类重新构建其对象模型。 Mechanic 也可以愉快地在这些 Car's 上工作，因为一切都在同一张赞美诗（或 DLL？）中歌唱：)
一个主要好处是，如果对象在其设计中发生变化，您只需更新 DLL，Web 服务和客户端应用程序就与该过程完全解耦。

注意：然后创建Facade 第二层使用 Web 服务并从 XML 结果自动生成对象通常很有用。

我希望这是有道理的，如果没有，那么请大声疾呼，我会澄清。

【讨论】：

【解决方案3】：

如果您直接绑定到 Web 服务类型，您将引入耦合。如果 Web 服务将来发生变化，这可能会产生不希望的副作用，这意味着需要进行大量代码更改。

例如，如果您今天使用的是 .asmx Web 服务，那么明天转为 WCF 会怎样？如果您使用了 WCF 不会序列化的类型，这可能意味着对您的代码进行相当多的更改。

从长远来看，创建特定的客户端对象然后在 Web 服务数据合同类型之间进行转换通常会更好。看起来工作量很大，但是当需要重构时，这通常会得到很大回报，因为您的更改已本地化在一个地方。

【讨论】：

【解决方案4】：

您可以做的一件事是使用您想要的任何附加功能创建与 Web 服务数据协定相对应的客户端类，并将 Web 服务引用设置为重用现有类型。那么就没有理由创建一个额外的包装类来绑定。

【讨论】：

【解决方案5】：

这实际上取决于您从 Web 服务中获得什么。如果它们是简单的数据传输对象并且您只显示数据，那么可以，您可以绑定。如果您打算编辑对象，它可能没有用，因为您需要跟踪更改。

您在客户端上的对象和/或集合是否跟踪更改？如果是这样，您可以使用它们。

如果您没有更改跟踪，那么您将需要自己跟踪更改，因此您可能需要翻译对象或将它们包装在某些东西中以跟踪更改。

同样，这真的取决于你得到什么，他们支持什么，你用他们做什么，以及服务器想要什么响应改变。

【讨论】：