Spring MVC Controller 逻辑边界终极指南：到底该写什么？

在编写 Spring MVC 应用时，你有没有思考过一个问题：Controller 里到底能写多少逻辑？

这个问题没有官方的标准答案，但在实际的工程项目中，边界一旦变得模糊，代码就一定会走向失控。一个清晰、简洁的 Controller 层是良好架构的基石，它能有效分离关注点，提升代码的可维护性与可测试性。反之，臃肿的 Controller 会成为维护的噩梦。

一个核心原则是：Controller 里应该只写 “流程控制逻辑”，而绝不应该写 “业务决策逻辑”。

一、先分清两种“逻辑”

很多关于 Controller 职责的争论，根源在于没有分清“逻辑”的种类。明确边界是规范代码的第一步。

1. 可以写在 Controller 的逻辑

这类逻辑的共同点是：不依赖具体的业务规则，也不影响核心的数据一致性。它们更像是请求的“交通警察”和“快递员”。

• 参数接收与转换：将 HTTP 请求中的参数（如 JSON、表单数据）解析并转换为 DTO（Data Transfer Object）或 VO（View Object）。
• 参数基本校验：执行非业务性的校验，如字段非空、长度、格式（如邮箱、手机号）等。这通常借助 JSR-303 等校验框架完成，而非手写业务规则。
• 接口路由与调用顺序：决定哪个请求由哪个处理方法处理，并协调调用后续的 Service 或组件。
• 返回结果封装：将 Service 层返回的业务结果，封装成统一的 API 响应格式（如 Result<T> 对象）。

一个典型的示例代码是这样的：

@PostMapping("/order/create")
public Result<?> create(@RequestBody @Valid OrderDTO dto) {
    orderService.create(dto);
    return Result.success();
}

在这个例子中，Controller 的职责非常清晰：接收 → 转发 → 返回。它不关心订单如何创建，只负责将创建订单的请求传递给真正干活的 Service 层。

2. 不能写在 Controller 的逻辑

这类逻辑的共同点是：一旦写进 Controller，就会导致逻辑碎片化，变得难以复用和维护，通常涉及到核心的业务逻辑。

• 业务状态判断：例如，判断订单是否已关闭、用户是否有资格参与某活动。
• 复杂的权限规则：超越了简单的角色或权限码校验，需要结合具体数据进行判断。
• 领域模型校验：依赖于多个实体或复杂规则的校验，如“库存是否充足”、“优惠券是否适用于当前商品”。
• 多步骤的一致性控制：需要保证多个操作要么全部成功，要么全部回滚的流程。

一个常见的错误示例如下：

if (order.isClosed()) {
    throw new BizException("订单已关闭");
}

如果将这种业务状态判断写在 Controller 里，后果就是：同一个业务规则（如“订单关闭后不可操作”）会分散在无数个 Controller 方法中。任何规则变更，都需要找到所有相关接口进行修改，极易遗漏，这便是典型的“业务规则碎片化”。

二、Controller 写多了逻辑，会发生什么？

当过多的业务逻辑被塞进 Controller，一系列工程问题会接踵而至。

1. 接口开始“自我封闭”，代码无法复用

一旦业务逻辑被写入 Controller，它就与特定的 HTTP 入口强绑定了。这会导致：

• 定时任务无法复用：一个需要每天凌晨执行的批处理任务，无法直接调用 Controller 方法。
• 消息消费者无法复用：当从消息队列（如 Kafka）中消费到相同业务事件时，你无法复用 Controller 里的逻辑。
• 其他 Controller 无法复用：另一个需要相同业务操作的接口，无法直接调用。

最终，开发者往往只能选择“复制粘贴”，导致同一段业务逻辑的代码副本散落在系统的各个角落，为后续的修改和维护埋下巨大的隐患。

2. 事务边界被打散，职责发生错位

Controller 本不该关心事务的边界，但当业务逻辑堆积在此，开发者很可能会在 Controller 方法上添加 @Transactional 注解：

@Transactional
@PostMapping("/update")
public void update(){
    // ... 这里混杂了业务逻辑
}

这是一种典型的职责错位。事务管理应该是 Service 层的职责，因为它最清楚哪些数据库操作需要作为一个原子单元。将事务注解放在 Controller，不仅模糊了分层架构的边界，还可能导致事务范围过大（包含了非数据库操作）或意外的长事务。这本质上不是一个技术难题，而是一个系统设计问题。

3. 测试成本急剧上升

充斥着业务逻辑的 Controller 层会给测试带来巨大麻烦：

• 难以进行单元测试：你需要 Mock 整个 HTTP 请求上下文（如 HttpServletRequest, HttpServletResponse），这非常笨重。
• 依赖 Web 环境：测试必须启动 Servlet 容器（如 Tomcat）或使用 MockMvc，这比测试一个纯 Java 对象要慢得多。
• Mock 成本高：业务逻辑越复杂，需要 Mock 的依赖（如其他 Service、Repository）就越多，测试用例的编写和维护成本也越高。

相比之下，Service 层的逻辑是天生适合测试的。它们是普通的 Java 类，可以轻松地通过依赖注入进行 Mock，编写快速、独立的单元测试来验证核心业务规则。

三、一个简单的判断标准

如何快速判断一段代码该不该放在 Controller 里？你可以问自己下面这三个问题：

1. 这段逻辑会不会被多个入口（如其他Controller、定时任务、消息监听器）复用？

   • 如果答案是“会”，那么它应该属于 Service层。

2. 这段逻辑是否会影响数据库或其他资源的事务一致性？

   • 如果答案是“是”，那么它必须放在 Service 层进行统一的事务管理。

3. 这段逻辑是否属于具体的业务规则或领域知识？

   • 如果答案是“是”，那么它毫无争议地应该归属于 Service 层或领域模型。

只要对以上任何一个问题的回答是“是”，那么这段代码就不应该出现在 Controller 中。

将 Controller 保持轻薄，不仅仅是遵循某种设计教条，更是为了应对软件不断演化的现实。清晰的职责划分能让你的代码库在面对需求变更时更加从容，让团队协作更加高效。如果你对如何构建清晰的代码架构有更多想法，欢迎在云栈社区与更多开发者一同交流探讨。