Spring Boot 从接口设计到业务编排 - 详解

@RestController
@RequestMapping("/api/user")
public class UserController {
    @Autowired
    private UserService userService;
    @PostMapping("/create")
    public Result createUser(@RequestBody UserDTO dto) {
        return Result.success(userService.createUser(dto));
    }
}

为什么要使用 `@RequestMapping("/api/user")`？

便于管理同一业务域的接口
避免路由冲突
更符合 REST 的语义化设计

为什么使用 `@RequestBody`？

接收 JSON 格式参数
可映射为 DTO 类
便于字段校验

2.2 参数接收方式：HTTP 的三种常见模式

Spring Boot 完整支持 Web API 中的所有参数类型。

（1）@RequestParam：用于接收 URL 参数（GET 常用）

GET /api/user/detail?id=1

接收

@GetMapping("/detail")
public Result detail(@RequestParam Long id) {
    return Result.success(userService.detail(id));
}

（2）@RequestBody：接收前端发送的 JSON（POST 常用）

{
  "name": "Alice",
  "email": "alice@example.com"
}

接收

@PostMapping("/update")
public Result update(@RequestBody UserDTO dto) {
    return Result.success(userService.update(dto));
}

（3）@PathVariable：接收路径变量

GET /api/user/11

接收

@GetMapping("/{id}")
public Result getUser(@PathVariable Long id) {
    return Result.success(userService.detail(id));
}

2.3 为什么需要统一返回结构？

在企业开发中，不可能让每个 Controller 自己决定响应格式，这会导致前端无法稳定解析数据。

统一响应结构的好处包括：

前端解析更简单，只需判断 code == 0
后端接口风格一致
异常情况统一处理
接口文档更加规范

通用结构如下：

{
  "code": 0,
  "msg": "success",
  "data": { ... }
}

使用 Result 包装类即可实现。

三、业务逻辑层（Service）：项目的核心大脑

Service 层是整个项目的业务中心，它负责执行流程、编排逻辑、做条件判断、验证参数、决定是否允许数据写入数据库。

3.1 为什么不能把业务写在 Controller？

虽然 Controller 写业务“看起来更快”，但会导致：

Controller 越写越大，无法维护
无法复用逻辑
无法进行单元测试
无法进行事务控制（Service 才允许）
系统结构失去扩展性

因此，企业级项目中统一要求：
Controller 只能做“输入输出”，其余全部在 Service。

3.2 标准 Service 写法

业务接口：

public interface UserService {
    UserVO createUser(UserDTO dto);
    UserVO detail(Long id);
    Boolean update(UserDTO dto);
}

业务实现：

@Service
public class UserServiceImpl implements UserService {
    @Autowired
    private UserRepository userRepository;
    @Override
    public UserVO createUser(UserDTO dto) {
        // 1. 校验邮箱是否重复
        if (userRepository.findByEmail(dto.getEmail()).isPresent()) {
            throw new BusinessException("邮箱已存在，无法重复注册");
        }
        // 2. 创建实体对象
        UserEntity entity = new UserEntity();
        entity.setName(dto.getName());
        entity.setEmail(dto.getEmail());
        entity.setCreateTime(LocalDateTime.now());
        // 3. 写入数据库
        userRepository.save(entity);
        // 4. 返回 VO
        return new UserVO(entity.getId(), entity.getName(), entity.getEmail());
    }
}

这段代码体现了企业开发中常见的业务处理方式：

校验参数
判断状态（例如是否重复、是否满足业务条件）
进行业务逻辑组合
操作数据库
组装返回结果

3.3 参数校验的重要性

后端需要保证数据的可靠性，例如：

public class UserDTO {
    @NotBlank(message = "姓名不能为空")
    private String name;
    @Email(message = "邮箱格式不正确")
    private String email;
}

在 Controller 中使用：

public Result createUser(@Valid @RequestBody UserDTO dto)

这样读者只需关注业务逻辑，参数合法性交给 Spring 校验。

四、数据库访问层：Repository 与 Mapper 的实战写法（增强版）

Spring Boot 默认支持两种主流方式：
JPA（快速自动 SQL）
MyBatis（精细控制 SQL）
项目中常按业务复杂度选择。

4.1 JPA：适合 CRUD 项目的轻量方案

JPA 的优点：

无需写 SQL
使用实体对象操作数据库
支持分页、排序、动态查询
更符合“面向对象”的编程方式

实体类映射说明

@Entity
@Table(name = "t_user")
@Data
public class UserEntity {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;
    private String name;
    private String email;
    private LocalDateTime createTime;
}

说明：

@Entity：映射成数据库表
@Table(name = "t_user")：指定表名
@Id：主键字段
@GeneratedValue：自增主键策略

4.2 MyBatis：适用于复杂 SQL、业务量大的场景

MyBatis 的优点：

SQL 完全可控
性能更可优化
复杂查询使用 XML 更灵活
大型项目、大数据场景首选

Mapper 接口

@Mapper
public interface UserMapper {
    UserEntity selectByEmail(String email);
}

XML 定义 SQL

MyBatis 方式更接近传统关系型数据库使用方式，可精准控制执行效率与查询结构。

五、从接口到数据库

从前端请求到数据库写入的完整路径：

前端发送 JSON 请求
   ↓
Controller 接收 DTO、校验、调用 Service
   ↓
Service 执行业务判断、校验逻辑、组织流程
   ↓
Repository / Mapper 发起数据库操作
   ↓
数据库写入或查询
   ↓
Service 组装 VO
   ↓
Controller 返回 Result
   ↓
前端收到统一格式的响应

posted on 2026-01-30 17:15 ljbguanli 阅读(0) 评论(0) 收藏举报