在WCF服务的方法中使用输出参数是不好的做法吗？除了通常的“out参数令人困惑并表明方法不仅仅是一个东西”之外，我正在寻找其他原因，更多关于为什么out参数在WCF服务中特别糟糕。在我现在工作的地方，我们在WCF服务中有一条针对他们的规则，我正试图找出原因！就个人而言，我在特定的地方使用参数（例如称为TryParse()的方法）。所以，我有一些偏见，你说我只在特定的、有限的地方使用它。此外，您不能假设.Net应用程序会在另一端使用它。因为WCF提供作为SOAP或RESTWeb服务（以及其他通信类型）工作的接口，所以我不能保证WCF甚至支持参数以与非.Net消费者兼容。除此之外，WCF服务正在向消费者提供一个API，而该API应该提供一个接口，在对服务器方法的编码方式了解有限的情况下使用该接口。（不要假设编写WCF服务器的人就是在另一端编写客户端的人）。尝试在API上使用out参数似乎有点代码味道。据推测，人们会使用out参数将另一个值返回给消费者。考虑改用消息对象。消息对象具体包含需要从WCF服务器发送到其使用者的所有数据片段。例如，假设您在WCF服务器中公开了一个名为TryCreateUser的方法：boolTryCreateUser(stringname,stringemail,outUseruser){}您打算返回一个bool指示用户创建成功的位置，以及一个包含用户（如果成功）。我会创建一个新类UserCreationMessage：classUserCreationMessage{boolIsSuccessful;用户用户；}将这个消息对象返回给消费者，仍然可以获得多个返回值。但是，您现在返回的是一个连贯的对象，它对API的最终用户更具声明性。最后，我认为在API（例如WCF服务器）中使用out参数是不好的做法，因为为此服务创建使用者的程序员必须能够轻松查看API并使用它，而无需跳过一个环存在一个输出参数。由于存在更好的设计，因此请使用它。API需要更高的编码标准，尤其是在暴露给最终消费者的接口中。一个原因是输出参数由添加服务引用时生成的代理类处理——这是额外的开销。另一个原因：根据这篇文章，即使原始的out参数在您使用它时是最后一个，但它变成了第一个-令人困惑并可能导致复杂性错误，这可能需要时间来解决，直到有人弄清楚它。个人观点：WCF操作（方法）应该做点什么，返回点什么。它可以做很多事情，但只返回一个结果——如果你需要一些额外的东西，只需让它返回复杂类型，你所需要的只是该类型的数据字段。以上是C#学习教程：在WCF服务的方法中有输出参数是不好的做法吗？如果所有分享的内容对你有用，需要进一步了解C#学习教程，希望大家多多关注。本文收集自网络，不代表立场。如涉及侵权，请点击右侧联系管理员删除。如需转载请注明出处：
