Question

你应该为每个方法制作一个请求/响应对象，还是每个服务都有一个？

如果我在所有方法中使用它，我的服务请求对象中只有5个不同的东西，因为我对几乎所有方法使用相同的输入。

响应对象只有一个字典，一个bool，一个表示ID的int，以及一个名称的字符串值。我不确定我是否看到了创建一堆独立对象的重点，这些对象内部都有相同的内容，而不是只使用一个对象。

什么是最佳做法？

Answer 1

我会建议每个方法只包含该方法提供和返回的请求和响应信息。原因是，当从wsdl生成代理代码时，调用客户端对该方法的期望是更清楚的。

Answer 2

我同意Nick Ryan的回答。查看我前一段时间写的博客，了解详情http://www.link-intersystems.com/blog/2012/01/12/pros-and-cons-of-service-layer-designs/

Answer 3

IMO没有一个适合所有人的答案 - 这取决于

如果你对网络的两端都有“控制”（即你自己的.NET客户端是WCF服务的唯一使用者），那么共享类型是有意义的（即在客户端和服务器上重用相同的实体程序集）。如果您这样做，那么拥有一个在项目中所有服务共享的公共实体集将节省重新发明轮子的时间（例如，结果代码，分页信息，其他自定义上下文信息等）。您也可以使用生成的服务引用，或直接使用ClientBase＆lt;＆gt;在您的客户端对抗共享的ServiceContract接口。在这种情况下，只要它正确地序列化/反序列化，您就不会真正“关心”数据在网络中的样子。

但是，如果您的WCF服务中还有其他非.NET使用者，那么还有其他注意事项。

DataContractSerializer为每个方法（通常是Method和MethodResponse）创建请求和响应模式，并在两者上公开方法签名（包括参数变量名称）。它将取决于客户端WSDL映射技术，以确定请求和响应中的公共实体是否“滚动”为可重用实体，或者每次是否将创建新实体。

使用DCS，没有“压力”将不相关的字段/参数包装到单个类中 - 例如您的留言签名可以是

public DoSomethingResult DoSomething(int parameter1, SomeEntity parameter2, string parameter3);

您还可以考虑MessageContracts。这会“强迫”您更多地考虑数据在整个线路中的样子，并且请求和响应包含在包装器实体中。 IMO MessageContracts在EAI场景中运行良好（例如，如果您有BizTalk消费者），因为您建议的常见响应消息可以在多个服务调用中重复使用。

HTH

WCF设计 - 一个请求和响应对象还是多个？

3 个答案: