wcf架构设计。 re：返回值

Question

您好，感谢您的意见。

我正在创建一个Web服务。 此Web服务将接受客户和客户帐户以及其他几个相关对象和属性等。

当网络服务收到请求时，我会尝试处理它 如果没有错误，我只需返回。如果有错误，我扔掉它。

我想知道这是否是最好的方法，或者我是否应该修改我的设计，以便我返回一个bool作为响应，甚至创建一个响应对象，可能包含原始请求对象加上状态，如果错误，错误列表（即：缺少字段，无效字段，分机）。

您将在设计中加入哪种返回方法？
1）如果没有错误则返回，如果错误则抛出错误 2）布尔成功 3）响应对象（包含原始请求对象？和详细结果）？

感谢您的任何建议。 史蒂芬

Answer 1

作为一般经验法则：如果情况不允许您成功完成请求，则抛出异常。如果您想要回传其他信息，例如订单号等，请使用返回值。通过布尔返回值发出完全失败信号通常不是一个好主意 - 调用者可以忽略/不检查。

现在因为它是外部源使用的WCF服务，所以不应该抛出异常 - 这是.NET特定的东西 - 而是抛出SOAP错误。您应该通过向您的操作添加一个或多个FaultContract属性，在服务提供的每项操作中将这些错误声明为服务合同的一部分：

[FaultContract(typeof(MyFault1))]
[FaultContract(typeof(MyFault2))]
[OperationContract]
void MyOperation()

您可以通过抛出FaultException或更具体的FaultException（一种可以指定exakt类型的错误的通用变体）在.NET WCF中轻松完成此任务。

马克

Answer 2

我认为这取决于谁将使用此服务，

如果您是唯一使用此服务的人，我建议您不要返回任何内容（或原始请求），如果出现问题则抛出异常。

如果该服务是供公众使用的，您应该返回一些包含错误的响应对象以及其他一些相关数据。

祝你好运

Answer 3

我想说这取决于'错误'是什么。如果错误与验证相关，但在正常的事件过程中预期，例如将无效的用户凭证传递给提供用户身份验证的服务，则返回指示请求结果的枚举值（成功，失败等）可能正常。但是，如果错误是由于在正常事件过程中不应发生的输入，那么我建议你从服务操作中抛出一个错误。抛出错误表示客户端应用程序出错并提供了服务不知道如何处理的输入。您可以使用WCF服务操作注册特定的故障合同，以便客户端应用程序知道操作可能会在特定情况下引发一些故障。客户端应用程序应该为这些错误提供异常处理程序，并在抛出一个错误时采取措施，否则它将意外终止。

作为一个基本的经验法则，我会说在特殊情况下抛出错误，例如客户端提供了服务操作不希望接收的输入。如果客户端提供的信息不正确但服务操作已经过程处理，请在响应消息中返回状态代码或信息。