使用.NET 7 Minimal API时是否仍需使用请求处理程序？

通常，为了让应用程序逻辑具备可测试性，我们会创建类似这样的控制器：

[HttpGet]
public IActionResult SomeAction()
{
    var result = _someRequestHandler.Handle();
    return Ok(result);
}

这么做的原因主要有三点：

• 控制器本身难以测试
• 便于将业务逻辑与控制器分离
• 避免控制器因构造函数注入过多依赖而变得臃肿

但在.NET 7 Minimal API中，我们的“控制器方法”是以静态类形式存在的，测试起来很容易。现在我不确定的是：结合业界最佳实践，我们是否仍然应该使用请求处理程序？直接把所有逻辑写在Minimal API的“控制器操作”里总感觉不太合适，想听听看法。

结论：仍然建议使用请求处理程序（或类似的逻辑分离方式） #

虽然Minimal API的静态方法确实更容易测试，但直接把所有逻辑塞进API端点里，长期来看会带来不少问题，以下是几个核心原因：

1. 关注点分离依然是刚需 #

Minimal API的端点本质上是HTTP请求的入口/出口，它的职责应该仅限于处理HTTP层面的逻辑：比如参数绑定、验证请求合法性、转换响应格式（比如返回Ok/NotFound等）。而业务逻辑（比如数据处理、业务规则校验、调用服务等）属于另一层职责，应该单独抽离出来。

如果把业务逻辑直接写在端点里，会导致端点代码变得臃肿，既处理HTTP细节又处理业务，后续修改或排查问题时很难快速定位。

2. 代码复用与扩展性 #

请求处理程序（或专门的业务服务类）可以被多个端点复用。比如同一个业务逻辑可能被GET、POST或者其他不同的API端点调用，抽离成单独的处理程序后，不用在多个地方重复写相同代码。

另外，当业务逻辑需要扩展（比如加缓存、加日志、加事务）时，直接修改请求处理程序即可，不用改动所有调用它的端点；反之，如果逻辑都在端点里，每个端点都要单独修改，维护成本会指数级上升。

3. 测试的深度与灵活性 #

Minimal API的静态方法确实容易测试，但测试的只是“HTTP端点是否能正确返回结果”。而业务逻辑的测试应该更聚焦：比如单独测试某条业务规则是否生效、某个数据处理逻辑是否正确，这些测试不需要依赖HTTP上下文，直接测试请求处理程序会更高效。

而且，当业务逻辑复杂时，抽离后的处理程序可以更容易地进行单元测试、集成测试，甚至模拟各种边界场景，不用在测试中构建HTTP请求上下文。

4. 避免依赖膨胀的问题 #

虽然Minimal API的静态方法可以通过依赖注入获取服务，但如果把所有逻辑都写在端点里，后续难免会引入更多依赖（比如数据库上下文、第三方服务、日志服务等），最终还是会让端点代码变得臃肿。而请求处理程序可以按需封装依赖，让端点只依赖处理程序这一个入口，保持简洁。

折中方案：轻量级的逻辑分离 #

如果觉得传统的请求处理程序太繁琐，也可以用更轻量的方式，比如：

• 把业务逻辑抽离成静态方法或小型服务类，端点只负责调用这些方法并处理HTTP响应
• 使用MediatR这样的中介库，将请求与处理逻辑解耦，同时保持代码简洁

总之，核心原则是：让HTTP端点只做HTTP相关的事，把业务逻辑交给专门的组件处理，这和是否使用Minimal API无关，是通用的软件设计最佳实践。

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