WCF 设计 - 一个请求和响应对象还是多个？
您应该为每种方法创建一个请求/响应对象，还是应该为每个服务创建一个请求/响应对象？
如果我在所有方法中使用它，那么我的服务请求对象中将只包含 5 个不同的内容，因为我对几乎所有方法都使用相同的输入。
响应对象只有一个字典、一个 bool、一个表示 ID 的 int 以及一个表示名称的字符串值。我不确定我是否明白创建一堆单独的对象的意义，这些对象内部都具有相同的内容，而不是仅使用一个对象。
什么被认为是最佳实践？
Should you make one request/response object for each method or should you have one per service?
My service request object would only have 5 different things in it if I used it across all methods as I use the same inputs for almost all methods.
The response object would only have a dictionary, a bool, an int that represents an ID, and a string value for the name. I'm not sure I see the point in creating a bunch of separate objects that all have the same things inside of them instead of just using one object.
What is considered the best practice?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我建议每个方法只包含该方法提供和返回的请求和响应信息。原因是，当客户端从 wsdl 生成代理代码时，调用客户端会更清楚该方法的期望是什么。
I would advise one for each method containing only the request and response information that that method provides and returns. The reason being that it will be clearer to calling clients what the expectations of that method are when they generate their proxy code from the wsdl.
我同意尼克·瑞安的回答。查看我前段时间写的博客了解详细信息
I agree with Nick Ryan's answer. Check out the blog I wrote some time ago for details 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，没有“压力”将不相关的字段/参数包装到单个类中 - 例如，您的消息签名可以是
您也可以考虑 消息合同。这“迫使”您更多地考虑网络上的数据是什么样子，并且请求和响应包含在包装器实体中。 IMO MessageContracts 在 EAI 场景中运行良好（例如，如果您有 BizTalk 使用者），因为您建议的通用响应消息可以在多个服务调用中重用。
华泰
IMO there isn't a one-size-fits all answer - it depends
If you have 'control' over both ends of the wire (i.e. your own .NET client is the only consumer of the WCF services), then shared type makes sense (i.e. reusing the same entity assemblies on client and server). If you do this, then having a common set of entities which is shared across all services in your project would save time reinventing the wheel (e.g. for Result Codes, Pagination Information, additional custom contextual information, etc). You can also either use generated service refernces, or directly use ClientBase<> in your client against shared ServiceContract interfaces. In this case, you don't really 'care' what the data looks like across the wire, as long as it serializes / deserializes correctly.
However, if there are other, non .NET consumers of your WCF serice then there are other considerations.
DataContractSerializer creates a request and response schema for each method (usually Method, and MethodResponse) with the method signature exposed on both (including parameter variable names). It will depend on the client WSDL mapping technology as to whether common entities in the request and response will be 'rolled' into reusable entities, or whether new entities will be created each time.
With DCS there is no 'pressure' to wrap unrelated fields / parameters into a single class - e.g. your message signature can be
You can also consider MessageContracts. This 'forces' you to think a lot more about what the data looks like across the wire, and the requests and responses are contained in wrapper entities. IMO MessageContracts work well in EAI scenarios (e.g. if you have a BizTalk consumer), as a common response message such as you are suggesting can then be reused across multiple service calls.
HTH