Spring Boot 3.x 分层架构实战：Controller/Service/Mapper/Entity 职责边界与 4 个常见误区

Spring Boot 3.x 分层架构实战：Controller/Service/Mapper/Entity 职责边界与常见误区解析

在Spring Boot项目中，分层架构设计是构建可维护、可扩展应用程序的基石。然而，许多开发者在实际项目中常常模糊各层之间的职责边界，导致代码耦合度高、难以维护。本文将深入探讨Controller、Service、Mapper和Entity四层的核心职责，并通过四个典型误区案例，帮助开发者建立清晰的分层架构认知。

1. 分层架构的核心价值与设计原则

分层架构之所以成为企业级应用开发的标准范式，源于其带来的三大核心价值： 解耦 、 复用 和 可测试性 。在Spring Boot生态中，标准的分层通常包含以下四层：

• Controller层 ：处理HTTP请求和响应，是系统的入口点
• Service层 ：封装业务逻辑，协调多个数据操作
• Mapper层 ：负责与数据库交互，执行CRUD操作
• Entity层 ：映射数据库表结构，承载数据实体

正确的分层应当遵循以下设计原则：

1. 单一职责原则 ：每个层/类只做一件事
2. 依赖倒置原则 ：高层模块不直接依赖低层模块
3. 开闭原则 ：对扩展开放，对修改关闭
4. 迪米特法则 ：最少知识原则，减少层间耦合

// 典型的分层调用链示例
@RestController
@RequestMapping("/users")
public class UserController {
    private final UserService userService;
    
    @GetMapping("/{id}")
    public ResponseEntity<UserDTO> getUser(@PathVariable Long id) {
        return ResponseEntity.ok(userService.getUserById(id));
    }
}

@Service
public class UserService {
    private final UserMapper userMapper;
    
    public UserDTO getUserById(Long id) {
        User user = userMapper.selectById(id);
        return convertToDTO(user);
    }
}

2. 误区一：Controller越权处理业务逻辑

2.1 典型反模式

许多初级开发者容易在Controller中直接编写业务逻辑，例如：

@RestController
public class OrderController {
    @Autowired
    private OrderMapper orderMapper;
    
    @PostMapping("/orders")
    public ResponseEntity<String> createOrder(@RequestBody OrderDTO orderDTO) {
        // 直接进行库存检查（应属于Service层职责）
        Integer stock = orderMapper.checkStock(orderDTO.getProductId());
        if (stock < orderDTO.getQuantity()) {
            return ResponseEntity.badRequest().body("库存不足");
        }
        
        // 直接操作数据库（应通过Service层）
        orderMapper.insert(orderDTO);
        return ResponseEntity.ok("订单创建成功");
    }
}

2.2 问题分析

这种写法存在三个严重问题：

1. 违反单一职责原则 ：Controller应只负责请求/响应处理
2. 难以复用业务逻辑 ：相同的库存检查逻辑无法被其他Controller复用
3. 事务管理困难 ：跨多个数据库操作时无法保证原子性

2.3 修正方案

正确的做法是将业务逻辑下沉到Service层：