您好，感谢您的意见。
我正在创建一个网络服务。 该网络服务将接受客户和客户帐户以及其他一些相关对象和属性等。
当网络服务收到请求时，我会尝试处理它。
如果没有错误，我只是返回。如果有错误，我抛出它。
我想知道这是否是最好的方法，或者我是否应该修改我的设计以便我返回一个布尔值作为响应，或者甚至创建一个响应对象，它可能包含原始请求对象加上一个状态，如果error，错误列表（即：缺失字段、无效字段、分机）。
您会在设计中采用哪种返回方式？
1) 如果没有错误则返回，如果错误则抛出错误
2）布尔成功
3) 响应对象（包含原始请求对象？和详细结果）？
感谢您的任何建议。 史蒂文
【问题讨论】：
标签： wcf web-services architecture
作为一般经验法则：如果情况不允许您成功完成请求，则抛出异常。如果您想回传其他信息，例如订单号等，请使用返回值。通常，通过布尔返回值发出完全失败的信号并不是一个好主意——调用者可能会忽略/不检查它。
现在，由于它是由外部资源使用的 WCF 服务，因此您不应该只抛出异常（这是 .NET 特定的东西），而应该抛出 SOAP 错误。您应该通过向您的操作添加一个或多个 FaultContract 属性，将这些故障声明为您的服务提供的每个操作的服务合同的一部分：
[FaultContract(typeof(MyFault1))]
[FaultContract(typeof(MyFault2))]
[OperationContract]
void MyOperation()
您可以在 .NET WCF 中通过抛出 FaultException 或更具体的 FaultException（您可以在其中指定具体故障类型的通用变体）轻松地做到这一点。
马克
【讨论】：
我会说这取决于“错误”是什么。如果错误与验证相关但在正常事件过程中是预期的，例如将无效的用户凭据传递给提供用户身份验证的服务，则返回指示请求结果（成功、失败等）的枚举值可能是可以的。但是，如果错误是由于正常事件过程中不应发生的输入引起的，那么我建议您从服务操作中抛出错误。抛出错误表明客户端应用程序出错并且提供了服务不知道如何处理的输入。您可以使用 WCF 服务操作注册特定的故障协定，以便客户端应用程序知道该操作可能会在特定情况下引发多个故障之一。客户端应用程序应该为这些错误提供异常处理程序，并在抛出异常时采取措施，否则将意外终止。
作为一个基本的经验法则，我会说在特殊情况下抛出错误，例如客户端提供了服务操作不希望收到的输入。如果客户端提供的信息不正确，但服务操作已被编程处理，则在响应消息中返回状态码或信息。
【讨论】：
我认为这取决于谁会使用这项服务，
如果您是唯一使用此服务的人，我建议您不返回任何内容（或原始请求）并在出现问题时抛出异常。
如果服务是供公众使用的，您应该返回一些包含错误的响应对象，以及一些其他相关数据。
祝你好运
【讨论】：