ASP.NET Core Web API：服务层抛异常还是返回IActionResult？

问题背景 #

我正在开发一个带控制器的ASP.NET Core Web API项目，所有API控制器都继承自包含NotFound()方法的ControllerBase。当找不到客户端请求的资源时，我会在控制器中使用该方法。但有时我想将所有逻辑从控制器动作封装到独立服务中，此时无法直接使用NotFound()方法。

我想知道，当找不到资源时，该服务是应该抛出自定义MyNotFoundException异常，再通过全局异常处理器返回404状态码给客户端，还是应该返回IActionResult，在服务方法中返回new NotFoundObjectResult()（类似ControllerBase.NotFound()）而非抛出异常？

权衡点 #

让我纠结的是这个决策带来的利弊：

• 若选择让服务抛出异常，代码更简洁，因为服务不依赖IActionResult、NotFoundObjectResult等ASP.NET Core抽象；但抛出异常是开销较大的操作，服务器处理耗时比直接返回对象更长。
• 反之，若服务返回IActionResult，错误场景下处理更快，但会让服务与ASP.NET Core类型耦合。两种方案各有优劣，我无法抉择。

抛异常方案示例代码 #

控制器代码 #

[Route("api/users")]
[ApiController]
public class UsersController : ControllerBase
{
    // ... 无关代码 

    [HttpDelete("{id}")]
    [ProducesResponseType(StatusCodes.Status204NoContent)]
    [ProducesResponseType(StatusCodes.Status404NotFound)]
    public async Task<IActionResult> DeleteUser([Required] string id)
    {
        if (!ModelState.IsValid)
        {
            return BadRequest();
        }

        await userManagementService.DeleteUser(id); // 所有逻辑在该服务方法内

        return NoContent();
    }
}

服务层代码 #

public class UserManagementService : IUserManagementService
{
    // ... 无关代码
    public async Task DeleteUser(string id)
    {
        var user = await _dbContext.Users.FindAsync(id);
        if (user == null)
        {
            throw new MyNotFoundException($"User with id: {id} not found");
        }

        // ... 删除用户及清理相关资源的代码（如数据库外的内容服务器用户文件）
    }
}

返回IActionResult方案示例代码 #

控制器代码 #

[Route("api/users")]
[ApiController]
public class UsersController : ControllerBase
{
    // ... 无关代码 

    [HttpDelete("{id}")]
    [ProducesResponseType(StatusCodes.Status204NoContent)]
    [ProducesResponseType(StatusCodes.Status404NotFound)]
    public async Task<IActionResult> DeleteUser([Required] string id)
    {
        if (!ModelState.IsValid)
        {
            return BadRequest();
        }

        return await userManagementService.DeleteUser(id); // 所有逻辑在该服务方法内
    }
}

服务层代码 #

public class UserManagementService : IUserManagementService
{
    // ... 无关代码
    public async Task<IActionResult> DeleteUser(string id)
    {
        var user = await _dbContext.Users.FindAsync(id);
        if (user == null)
        {
            return new NotFoundObjectResult($"User with id: {id} not found");
        }

        // ... 删除用户及清理相关资源的代码（如数据库外的内容服务器用户文件）

        // ... 成功时返回
        return new NoContentResult();
    }
}

结论：不建议服务层返回IActionResult #

核心原则是服务层应专注于业务逻辑，避免与Web框架耦合，具体原因如下：

1. 解耦需求：服务层是业务逻辑的核心，应该可以独立于ASP.NET Core运行（比如后续迁移到其他框架、或者被控制台程序/桌面程序调用）。如果返回IActionResult，就把服务层和Web框架绑定死了，失去了分层架构的意义。
2. 异常开销的实际影响有限：虽然抛出异常确实有一定性能开销，但在"资源不存在"这种属于业务逻辑中的预期错误场景中，其发生频率通常不会高到成为性能瓶颈。如果你的系统确实有极高的QPS需求，可以通过缓存等手段提前拦截无效请求，而非牺牲架构合理性。
3. 全局异常处理更统一：通过自定义异常+全局过滤器的方式，可以统一处理所有404场景，避免在服务层重复编写返回NotFoundObjectResult的代码，同时也能统一错误响应格式（比如返回包含错误码、消息的标准JSON结构）。
4. 代码可读性与职责清晰：服务层抛出异常明确表示"当前操作无法完成，因为资源不存在"，控制器只需要处理正常流程，职责划分更清晰。而返回IActionResult会让服务层承担部分Web层的职责，混淆了分层边界。

如果担心异常处理的性能问题，可以考虑在服务层返回一个通用的Result<T>类型（自定义封装成功/失败状态），比如：

public class Result<T>
{
    public bool IsSuccess { get; set; }
    public T Data { get; set; }
    public string ErrorMessage { get; set; }
    public int? StatusCode { get; set; }
}

服务层返回这个对象，控制器再根据Result的状态转换为对应的IActionResult。这种方式既避免了与Web框架耦合，又不用抛出异常，兼顾了架构合理性和性能。

内容的提问来源于stack exchange，提问作者mlst