服务合同设计(业务签名)

Question

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

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

• extensibility:我可以在不改变interface
• compactness:的情况下将参数添加到上下文或结果中，即使我需要许多参数

，但定义中只有一个对象。

示例：

[OperationContract]    
DoSomethingResult DoSomething(DoSomethingContext context)

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

• 开销:我总是将响应属性包装到一个对象中。有时，结果对象没有properties
• versioning: WCF内置的契约版本控制，也许使用不同的版本来通知差异

可能更好。

事实上，我也使用了同样的方法，所以我需要得到一些反馈，建议，批评等等。

谢谢

Answer 1

我认为这是一个完全合法的方式来写你的合同。我使用这类契约从事过许多项目，这是一种乐趣--在开发过程中非常容易(只需向对象添加一个属性，您就可以完成)，这是一种适用于所有服务的简单明了的模式，允许为所有操作使用单一的验证方法。

针对你的关切：

• 我认为创建空对象的开销一点也不重要。除非成为一个问题，否则不要担心这一点。如果结果对象没有属性(即没有返回任何属性)，则只需返回
• 。返回空对象不会获得任何好处。
• 可以(也可能应该)在对合同进行版本时对这些对象进行版本化。您所做的一切并不妨碍您对对象进行版本控制。

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

Answer 2

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

我最担心的是，从消费者的角度来看，它根本不清楚您的服务是如何工作的。他们必须依靠单独的文档或错误信息。

如果声明了所需的参数，对于不熟悉您的代码的人(即刚刚下载了WSDL)，使用您的服务就容易多了。你也能得到很好的验证。

为了说明：

[OperationContract]     
DoSomethingResult DoSomething(DoSomethingContext context) 

vs

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

这一点主要与API的设计有关。与此无关的地方是您既是服务的作者，也是服务的使用者。

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

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