0

我正在设计一些服务，我想获得一些关于我正在使用的约定的反馈。

对于所有操作，我总是定义一个“上下文”对象和一个“结果”对象，因为有以下优点：

  • 可扩展性：我可以在不更改接口的情况下将参数添加到上下文或对象到结果
  • 紧凑性：定义中只有一个对象，即使我需要很多参数

例子：

[OperationContract]    
DoSomethingResult DoSomething(DoSomethingContext context)

无论如何，由于以下原因，我不确定这是不是最好的方法：

  • 开销：我总是将响应属性包装到一个对象中。有时，Result 对象没有属性
  • 版本控制：WCF 具有内置的合约版本控制，也许使用不同的版本来告知差异可能会更好

事实上，我也使用与普通方法相同的技术，因此获得一些反馈、建议、批评等对我来说很重要。

谢谢

4

2 回答 2

3

我认为这是编写合同的一种完全合法的方式。我已经使用此类合同参与了许多项目，这很愉快 - 在开发过程中非常容易（只需向对象添加一个属性就完成了），这是一种适用于所有人的简单明了的模式服务，并允许对所有操作使用单一验证方法。

针对您的担忧：

  • 我认为创建一个空对象的开销根本不重要。除非它成为一个问题，否则不要担心这一点。
  • 如果 Result 对象没有属性（即您没有返回任何内容），则只需返回 void。通过返回一个空对象，您不会获得任何东西。
  • 您可以（并且可能应该）在对合约进行版本控制时对这些对象进行版本控制。您正在做的事情绝不会阻止您对对象进行版本控制。

请注意，版本控制对象并不意味着将它们更改为DoSomethingResult_v1，DoSomethingResult_v2正如我之前所见。您应该使用命名空间进行版本化；它使事情更清晰，更干净。只需在操作协定和数据成员属性的 XML 命名空间中放置一个版本。

于 2011-02-13T07:50:45.453 回答
2

我认为这里没有任何性能问题，从代码所有者的角度来看，代码看起来很容易使用。

我最担心的是，从消费者的角度来看，您的服务是如何运作的并不清楚。他们将不得不依赖单独的文档或错误消息。

如果声明了所需的参数，那么不熟悉您的代码（即刚刚下载 WSDL）的人使用您的服务会容易得多。您还可以获得开箱即用的良好验证。

为了显示：

[OperationContract]     
DoSomethingResult DoSomething(DoSomethingContext context)

对比

[OperationContract]   
[FaultContract(typeof(CustomerNotFoundFault))]   
Customer GetCustomer(UInt32 customerId)

这一点主要与 API 的设计有关。这不那么相关的地方是您既是服务的作者又是服务的消费者。

我完全支持 Kirk Broadhurst 关于使用名称空间进行版本控制的建议。我使用它并且效果很好。

编辑：在二读时，我想我误读了你的帖子。我在这里假设您的参数和返回值对象是您在所有服务中使用的一些通用对象。如果它们确实特定于每项服务，那么这是我在很多场合都成功使用过的好方法。你会做得很好。

于 2011-02-13T13:01:09.430 回答