3

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

4

5 回答 5

2

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

  1. 大型复杂对象作为 Web 服务结果。
  2. ASP.NET Web 服务结果、代理类和类型转换。

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

这是我的两点：

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

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

例如（使用您的Car课程）：

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

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

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

注意：通常创建一个外观层第二层与 Web 服务一起使用并从 XML 结果自动生成对象会很有用。

我希望这是有道理的，如果没有，请大喊大叫，我会澄清。

于 2008-10-24T19:54:07.273 回答
0

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

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

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

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

于 2008-09-21T00:25:59.767 回答
0

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

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

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

于 2008-09-21T06:28:28.477 回答
0

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

于 2008-09-21T03:33:06.917 回答
0

If you are the owner of both the web service and the client.
And you need the parameters of the web service calls to be complex classes which contain not only data but also behavior (actual coded logic) then you are in a bit of a pickle when developing these web services using web service frame works.
As suggested in the answer by Rob Cooper you can use pure xml as web service parameters and xml serialization, but there is a cleaner solution.
If you are using Visual Studio 2005 (probably applies the same for 2008), You can customize the way VS creates you proxy as described in this article: Customizing generated Web Service proxies in Visual Studio 2005

This way you can tell VS to use your own classes instead of generating a proxy class.

Well when I think of it, it's pretty much same solution as proposed by Rob Cooper, with the little twist, that you wont be writing a Facade layer your self but will be using VS itself as this layer.

于 2008-10-24T21:25:05.780 回答