服务合同设计（运营签名）

Question

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

对于所有操作，我总是定义一个'Context'对象和一个'Result'对象，因为它具有以下优点：

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

示例：

[OperationContract]    
DoSomethingResult DoSomething(DoSomethingContext context)

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

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

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

谢谢

Answer 1

我认为这是签订合同的完全合法的方式。我曾经在这些合同中开展了很多项目，这很愉快 - 在开发过程中非常容易（只需在对象中添加一个属性，然后就完成了），这是一个适用于所有人的简单明了的模式服务，并允许所有操作的单一验证方法。

回应您的疑虑：

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

请注意，版本控制对象并不意味着将其更改为DoSomethingResult_v1，DoSomethingResult_v2，就像我之前看到的那样。你应该使用命名空间版本;它使事情更清晰，更清洁。只需在操作协定和数据成员属性中的XML命名空间中放置一个版本。

Answer 2

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

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

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

举例说明：

[OperationContract]     
DoSomethingResult DoSomething(DoSomethingContext context) 

VS

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

这一点主要与API的设计有关。如果这不是那么相关，那么您既是服务的作者，也是服务的消费者。

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

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