ASP.NET中CRUD删除操作：服务层应向控制器返回何种结果？

针对你的场景，直接返回ASP.NET MVC的StatusCode对象或整数状态码都不是理想方案，推荐采用自定义枚举或结果对象，以下是具体分析和实践方案：

不推荐的方案及原因 #

• 返回StatusCode对象：强依赖ASP.NET MVC框架类型，违反服务层与UI层解耦的设计原则，非Web模块调用时会引入不必要的依赖，无法复用服务逻辑。
• 返回整数状态码：语义模糊，调用方需要记住诸如404、204这类“魔法数字”对应的业务含义，后续扩展新的操作状态时，维护成本会急剧上升。

推荐方案 #

1. 自定义枚举（适合简单状态场景） #

定义一个语义明确的枚举，直接表示删除操作的结果状态，所有模块都能轻松理解和使用：

// 定义枚举
public enum PotatoDeleteResult
{
    Success,
    NotFound
}

服务层实现：

public async Task<PotatoDeleteResult> Delete(long potatoId, CancellationToken ct)
{
    var potato = await _potatoRepository.FindByIdAsync(potatoId, ct);
    if (potato == null)
    {
        return PotatoDeleteResult.NotFound;
    }
    
    await _potatoRepository.DeleteAsync(potato, ct);
    return PotatoDeleteResult.Success;
}

控制器中根据枚举返回对应状态码：

[HttpDelete("{potatoId:long}")]
public async Task<IActionResult> DeletePotato([FromRoute] long potatoId, CancellationToken ct)
{
    var result = await _potatoService.Delete(potatoId, ct);
    
    return result switch
    {
        PotatoDeleteResult.Success => NoContent(),
        PotatoDeleteResult.NotFound => NotFound(),
        _ => BadRequest()
    };
}

这种方案的优势是轻量、语义清晰，无额外依赖，完全符合分层架构的解耦要求。

2. 自定义结果对象（适合复杂业务场景） #

如果后续业务需要返回更多操作上下文（比如删除失败的具体原因，如土豆被锁定），可以定义通用的结果对象：

// 通用结果对象
public class OperationResult
{
    public bool IsSuccess { get; set; }
    public OperationError Error { get; set; }
}

// 错误详情对象
public class OperationError
{
    public OperationErrorCode Code { get; set; }
    public string Message { get; set; }
}

// 错误码枚举
public enum OperationErrorCode
{
    ResourceNotFound,
    ResourceLocked
    // 可根据业务扩展其他错误码
}

服务层实现：

public async Task<OperationResult> Delete(long potatoId, CancellationToken ct)
{
    var potato = await _potatoRepository.FindByIdAsync(potatoId, ct);
    if (potato == null)
    {
        return new OperationResult
        {
            IsSuccess = false,
            Error = new OperationError
            {
                Code = OperationErrorCode.ResourceNotFound,
                Message = "指定的土豆不存在"
            }
        };
    }

    if (potato.IsLocked)
    {
        return new OperationResult
        {
            IsSuccess = false,
            Error = new OperationError
            {
                Code = OperationErrorCode.ResourceLocked,
                Message = "该土豆已被锁定，无法删除"
            }
        };
    }
    
    await _potatoRepository.DeleteAsync(potato, ct);
    return new OperationResult { IsSuccess = true };
}

控制器中处理逻辑：

[HttpDelete("{potatoId:long}")]
public async Task<IActionResult> DeletePotato([FromRoute] long potatoId, CancellationToken ct)
{
    var result = await _potatoService.Delete(potatoId, ct);
    
    if (result.IsSuccess)
    {
        return NoContent();
    }

    return result.Error.Code switch
    {
        OperationErrorCode.ResourceNotFound => NotFound(result.Error.Message),
        OperationErrorCode.ResourceLocked => StatusCode(StatusCodes.Status423Locked, result.Error.Message),
        _ => BadRequest(result.Error.Message)
    };
}

这种方案扩展性极强，能承载丰富的业务上下文信息，适合复杂的业务场景。

总结 #

• 简单场景下优先使用自定义枚举，兼顾简洁性与语义清晰；
• 复杂业务场景选择自定义结果对象，满足扩展需求；
• 两种方案都能实现服务层与UI层的解耦，让非Web模块也能友好调用服务逻辑。

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