您应该为每个方法创建一个请求/响应对象，还是应该为每个服务创建一个？
如果我在所有方法中使用它，我的服务请求对象中将只有 5 个不同的东西，因为我对几乎所有方法都使用相同的输入。
响应对象将只有一个字典、一个布尔值、一个表示 ID 的 int 和一个用于名称的字符串值。我不确定我是否明白创建一堆单独的对象的意义，这些对象内部都有相同的东西，而不是只使用一个对象。
什么是最佳实践？
【问题讨论】：
标签： wcf architecture request response
我会建议每个方法都只包含该方法提供和返回的请求和响应信息。原因是当客户从 wsdl 生成代理代码时，调用客户该方法的期望是什么会更清楚。
【讨论】：
我同意尼克瑞恩的回答。详情请查看我前段时间写的博客http://www.link-intersystems.com/blog/2012/01/12/pros-and-cons-of-service-layer-designs/
【讨论】：
IMO 没有万能的答案——这取决于
如果您对线路的两端都有“控制权”（即您自己的 .NET 客户端是 WCF 服务的唯一使用者），那么共享类型是有意义的（即在客户端和服务器上重用相同的实体程序集）。如果您这样做，那么拥有一组在项目中的所有服务之间共享的通用实体将节省重新发明轮子的时间（例如，用于结果代码、分页信息、其他自定义上下文信息等）。您也可以使用生成的服务引用，或者直接在客户端中使用 ClientBase 来对抗共享的 ServiceContract 接口。在这种情况下，您并不真正“关心”数据在网络上的样子，只要它正确地序列化/反序列化即可。
但是，如果您的 WCF 服务有其他非 .NET 使用者，那么还有其他注意事项。
DataContractSerializer 为每个方法（通常是 Method 和 MethodResponse）创建请求和响应模式，并在两者上公开方法签名（包括参数变量名称）。这取决于客户端 WSDL 映射技术是否将请求和响应中的公共实体“滚动”为可重用实体，或者是否每次都创建新实体。
使用 DCS 将不相关的字段/参数包装到单个类中没有“压力” - 例如。你的消息签名可以是
public DoSomethingResult DoSomething(int parameter1, SomeEntity parameter2, string parameter3);
您也可以考虑MessageContracts。这“迫使”您更多地考虑数据在网络上的样子，并且请求和响应包含在包装器实体中。 IMO MessageContracts 在 EAI 场景中运行良好（例如，如果您有 BizTalk 使用者），因为您建议的常见响应消息可以在多个服务调用中重复使用。
HTH
【讨论】：