保姆级教程：手写三层架构 vs MyBatis-Plus

在 Java 后端开发中，如何优雅地处理数据库操作一直是个热门话题。是从零开始手写 SQL，还是拥抱高度自动化的工具？今天我们就来一场“硬核拆解”，看看传统三层架构（DAO层）与MyBatis-Plus在实战中的碰撞。

一、 核心概念梳理

在深入代码之前，我们先明确这两个选手的“生态位”：

1. 三层架构 (MVC 延伸)：指 Controller（控制层）、Service（业务层）、Mapper/DAO（持久层）。手写模式下，我们需要为每个实体类编写 XML SQL 语句。

2. MyBatis-Plus (MP)：它是 MyBatis 的增强工具，在 MyBatis 的基础上只做增强不做改变。其核心口号是：让 CRUD 变得极其简单。

二、 实战对比：以“用户信息管理”为例

假设我们有一个数据库表 user，包含 id, username, email 等字段。

1. 手写三层架构（传统模式）

在这种模式下，即使是简单的“根据 ID 查询”，你也需要经历以下步骤：

• Mapper 接口：定义 User selectById(Long id);

• XML 映射文件：手写 SQL。

  <select id="selectById" resultType="User">
      SELECT id, username, email FROM user WHERE id = #{id}
  </select>
  

• Service 层：调用 Mapper。

痛点： 当项目有 50 张表时，你需要写 50 个类似的 XML 文件，不仅重复劳动多，还容易在字段名上写错。

2. MyBatis-Plus 模式

使用 MP 后，世界瞬间清静了：

• Mapper 接口：只需继承 BaseMapper<T>。

  public interface UserMapper extends BaseMapper<User> {
      // 所有的 CRUD 已经自动注入，无需写 XML
  }
  

• Service 层：直接调用内置方法。

  User user = userMapper.selectById(1L);
  

三、 深度对决：谁更胜一筹？

四、 进阶：MP 的杀手锏——Lambda 条件构造器

手写 SQL 时，处理“动态搜索”是最痛苦的（各种 <if> 标签）。MP 引入了 Wrapper 机制：

// 需求：查询年龄大于 18 且名字包含 "张" 的用户
LambdaQueryWrapper<User> wrapper = new LambdaQueryWrapper<>();
wrapper.gt(User::getAge, 18)
       .like(User::getUsername, "张");

List<User> list = userMapper.selectList(wrapper);

这种链式编程不仅美观，还避免了硬编码字符串导致的 Bug。

五、 总结：我该怎么选？

• 选择手写模式（原生 MyBatis）的情况：

  1. 你的 SQL 极其复杂，涉及 5-10 张表的深层关联。

  2. 公司有严格的 DBA 审核制度，必须在 XML 中统一管理 SQL。

  3. 你是初学者，建议先手写，理解 SQL 执行原理。

• 选择 MyBatis-Plus 的情况：

  1. 追求效率，希望从繁琐的增删改查中解脱。

  2. 项目中存在大量单表操作或逻辑简单的多表操作。

  3. 想要更优雅的分页插件、逻辑删除、自动填充等高级功能。

一句话建议： 生产环境推荐使用 MyBatis-Plus 负责 80% 的常规操作，剩余 20% 的超复杂业务再通过手写 XML 解决。两者并不冲突，而是完美互补！