c# - 在 WCF 服务的方法中使用输出参数是不好的做法吗？

Question

我正在寻找超出通常的“输出参数令人困惑并表明该方法正在做不止一件事”式参数的原因，以及更多关于 WCF 服务中输出参数特别糟糕的地方。在我现在工作的地方，我们在 WCF 服务中有一条禁止使用它们的规则，我正在努力找出原因!

Answer 1

就个人而言，我在特定的地方使用 out 参数(例如名为 TryParse() 的方法)。所以，我有一些你提到的偏见，我只在特定的、有限的地方使用它。此外，您不能假设 .Net 应用程序将在另一端使用它。因为 WCF 提供了一个可用作 SOAP 或 REST Web 服务(以及其他通信类型)的接口(interface)，所以我不能保证 WCF 甚至会支持 out 参数以与非 .Net 使用者兼容。

除此之外，WCF 服务正在向使用者提供 API，而 API 应该提供一个接口(interface)，该接口(interface)应该在对服务器方法的编码方式了解有限的情况下使用。 (不要假设编写 WCF 服务器的人就是在另一端编写客户端的人)。尝试在 API 上使用 out 参数似乎有点代码味道。据推测，人们会使用 out 参数将另一个值返回给消费者。考虑改用消息对象。消息对象专门由需要从 WCF 服务器发送到其使用者的所有数据片段组成。例如，假设您在 WCF 服务器中公开了一个名为 TryCreateUser 的方法:

bool TryCreateUser(string name, string email, out User user){}

您打算返回一个 bool 值，指示用户创建成功发生的位置，如果成功则返回一个包含用户的用户对象。我将创建一个新类 UserCreationMessage:

class UserCreationMessage {
    bool IsSuccessful;
    User user;
}

将这个消息对象返回给消费者，仍然可以得到多个返回值。但是，您现在返回了一个连贯的对象，它对 API 的最终用户更具解释性。

最后，我认为在 API 中使用 out 参数是不好的做法，例如 WCF 服务器，因为为该服务创建使用者的程序员必须能够轻松查看 API 并使用它没有跳过 out param 存在的箍。由于存在更好的设计，因此请使用它。 API 需要更高的编码标准，尤其是在向最终消费者公开的界面中。