java DAO 为何要解耦业务

在 Java 开发中，DAO（Data Access Object）层之所以要“解耦业务”，核心目的可以概括为一句话：

让“数据怎么存”和“业务怎么做”互不影响，系统更易维护、扩展和测试。

下面从几个关键角度说明原因。

一、DAO 的职责是什么？

DAO 的核心职责只有一件事：

✅ 封装对数据源（数据库、文件、缓存等）的访问细节

它不应该关心：

• 下单流程怎么走
• 用户是否 VIP
• 业务流程是否要发短信

业务层（Service）才应该关心：

• 先查库存
• 再扣钱
• 最后生成订单

二、如果不解耦，会发生什么问题？

1️⃣ 业务代码里写 SQL（最典型反例）

public void createOrder(Order order) {
    Connection conn = ...
    String sql = "INSERT INTO orders ...";
    // 业务 + SQL 混在一起
}

问题：

• 改表结构 → 业务代码全改
• 想换数据库 → 业务代码重写
• 单元测试极难写

2️⃣ DAO 里写业务规则

public void saveUser(User user) {
    if (user.getAge() < 18) {
        throw new RuntimeException("未成年不能注册");
    }
    // 插入数据库
}

问题：

• “未成年不能注册”是业务规则，不是数据规则
• DAO 被业务污染，无法复用

三、解耦带来的核心好处

✅ 1. 单一职责（SRP）

每一层只做一件事。

✅ 2. 可替换性（技术解耦）

UserDao userDao = new MysqlUserDao();
// 以后可以换成
UserDao userDao = new RedisUserDao();

业务层完全不用改。

✅ 3. 更容易测试（Mock DAO）

@Test
public void testOrderService() {
    UserDao mockDao = mock(UserDao.class);
    OrderService service = new OrderService(mockDao);
    // 不连数据库也能测业务
}

✅ 4. 支持事务与业务编排

@Transactional
public void placeOrder() {
    userDao.lockUser();
    orderDao.save();
    inventoryDao.reduce();
}

事务在 业务层 控制，而不是 DAO。

四、解耦的典型分层结构

Controller
   ↓
Service（业务）
   ↓
DAO（数据访问）
   ↓
DB

依赖方向：

上层依赖下层接口，不依赖实现

五、一句话总结

DAO 解耦业务，是为了让“数据访问”成为可替换、可测试、可复用的基础设施，而不是业务的附属品。

如果你愿意，我可以：

• 用 一个完整下单示例 演示解耦前后区别
• 或讲 MyBatis / JPA 中 DAO 解耦的最佳实践