在WCF服务的方法中有输出参数是不好的做法吗？
我正在寻找除了通常的“out参数令人困惑并且指示方法不仅仅是一件事”的理由，而且更多关于WCF服务中输出参数特别糟糕的原因。 我现在在哪里工作，我们在WCF服务中有一个规则来反对它们，我正在努力找出原因！
就个人而言，我在特定的地方使用参数（例如名为TryParse（）的方法）。 所以，我有一些偏见，你谈到我只在特定的，有限的地方使用它。 此外，您不能假设.Net应用程序将在另一端使用它。 因为WCF提供了可作为SOAP或REST Web服务（以及其他通信类型）的接口，所以我不能保证WCF甚至支持params以与非.Net消费者兼容。
除此之外，WCF服务正在向消费者提供API，而API应该提供一个接口，应该在对服务器方法编码方式有限的知识的情况下使用。 （不要以为编写WCF服务器的人就是在另一端编写客户端的人）。 尝试在API上使用out参数似乎是代码味道。 据推测，人们会使用out param将另一个值返回给消费者。 请考虑使用消息对象。 消息对象具体由需要从WCF服务器发送给其使用者的所有数据片段组成。 例如，假设您在名为TryCreateUser的WCF服务器中公开了一个方法：
bool TryCreateUser(string name, string email, out User user){} 您打算返回bool，指示用户创建成功的位置，以及包含用户的User对象（如果成功）。 我会创建一个新类UserCreationMessage：
class UserCreationMessage { bool IsSuccessful; User user; }
将此消息对象返回给使用者，您仍然可以获得多个返回值。 但是，您现在返回了一个连贯的对象，这对API的最终用户更具说明性。
最后，我认为在API中使用out参数是不好的做法，例如WCF服务器，因为为此服务创建使用者的程序员必须能够轻松查看API并使用它而不会跳过一个外面的param存在的篮球。 由于存在更好的设计，请使用它。 API需要更高的编码标准，特别是在暴露给最终消费者的界面中。
一个原因是out参数由添加服务引用时生成的代理类处理 – 这是额外的开销。
另一个原因是：根据这篇文章 ，即使原始out参数在你消耗它时是最后一个，它也会变成第一个 – 令人困惑并且可能导致复杂性错误，这可能需要时间来解决，直到有人想出来。
个人观点：WCF操作（方法）应该做某事并返回一些东西。 它可能会做很多事情，但只返回一个结果 – 如果你需要额外的东西，只需让它返回复杂类型，你需要的所有东西都是那种类型的数据字段。