6

假设我正在构建一个 ASP.NET Web API 应用程序，它具有以下结构：

在此处输入图像描述

从图中可以看出，ASP.NET Web API 核心将与域服务层（例如，MembershipService具有、 等方法的类）对话，而我的服务类将与一个或多个存储库对话以处理操作。GetUsersCreateUser

很明显，服务操作（例如MembershipService.CreateUser方法）会由于多种原因（未满足的条件、存储库抛出的异常等）而失败，这就是我有疑问的地方。

您是否认为服务类应该处理异常并返回某种结果对象，例如以下对象：

public class OperationResult {

    public OperationResult(bool isSuccess) : this(isSuccess) {
        IsSuccess = isSuccess;
    }

    public OperationResult(bool isSuccess, Exception exception) : this(isSuccess) {
        Exception = exception;
    }

    public bool IsSuccess { get; private set; }
    public Exception IsSuccess { get; private set; }
}

public class OperationResult<TEntity> : OperationResult {

    public OperationResult(bool isSuccess) 
        : base(isSuccess) { }

    public OperationResult(bool isSuccess, Exception exception) 
        : base(isSuccess, exception) { }

    public TEntity Entity { get; set; }
}

还是您认为服务方法不应该像那样抽象异常，而应该直接或间接抛出异常（创建一个新的有意义的异常类型特定于操作并将抛出的异常作为其内部异常）？

4

3 回答 3

3

当您处于进程中时，请使用异常。

于 2013-01-07T19:51:47.407 回答
2

我认为避免异常没有任何意义。例外是有充分理由的，主要是为了使用！试着看大局：你正试图用老式的错误检查方式来改变异常机制。这样一来，您将失去异常的所有优点（例如将错误处理和常规代码、CallStack 等分离），而一无所获。

在这种情况下，我通常会在服务层捕获异常并将其重新包装为自定义异常（在 InnerException 字段中引用原始异常）。

于 2013-01-07T17:55:06.007 回答
1

从 Microsoft 的书中获取一页，Membership API 的实现抛出异常而不是处理它们并返回结果对象，所以只要您不控制客户端和 API，我认为这是最佳实践。

在您同时控制客户端和 API 的情况下，我个人偏好返回结果对象或错误消息。这样做的原因是我想记录捕获有关实际异常来源的详细信息，但我不希望所有可能出错的东西都出现异常，例如密码不正确。

在这种情况下，向用户发送一个简单的错误消息就绰绰有余了。根据实际经验，每次发生验证错误时将异常记录到事件日志或日志文件是操作人员的主要负担，他们试图确定是否发生实际故障或是否只是用户的错字.

于 2013-01-07T16:37:14.980 回答