为什么要使用java DAO层

在 Java（尤其是企业级开发，如 Spring、SSM、Spring Boot 等）项目中，DAO 层（Data Access Object，数据访问对象层） 是非常常见且重要的设计。使用 DAO 层主要有以下几个核心原因：

1. 分层解耦，职责清晰

DAO 层专门负责与数据库打交道（增删改查），而：

• Service 层：处理业务逻辑
• Controller 层：处理请求和响应

这样每一层只关心自己的职责，代码结构更清晰，便于维护。

没有 DAO 层时，SQL 可能写在 Service 甚至 Controller 里，后期极其混乱。

2. 隔离业务逻辑与数据库细节

DAO 层屏蔽了：

• 使用什么数据库（MySQL / Oracle / PostgreSQL）
• 使用什么框架（JDBC / MyBatis / JPA / Hibernate）

业务层只调用 DAO 接口，不关心底层如何实现。

✅ 好处：

• 数据库迁移更容易
• 技术栈替换成本更低

3. 提高代码复用性

多个 Service 或模块可能需要：

• 根据用户ID查用户
• 根据条件查订单

把这些操作放在 DAO 层，可以避免重复写 SQL 和数据库代码。

4. 方便测试和 Mock

DAO 通常是接口 + 实现：

public interface UserDao {
    User findById(Long id);
}

在测试 Service 时，可以：

• 用 Mock 框架模拟 DAO
• 不连真实数据库也能测试业务逻辑

✅ 提升测试效率和稳定性

5. 便于事务和管理统一

在 Spring 中：

• DAO 只负责数据访问
• Service 用 @Transactional 统一管理事务

如果没有 DAO 层，事务边界容易混乱。

6. 符合成熟架构规范

主流架构普遍采用：

Controller
   ↓
Service
   ↓
DAO
   ↓
Database

这是经过大量项目验证的最佳实践。

7. 配合 ORM 框架更自然

无论是：

• MyBatis（Mapper 本质就是 DAO）
• JPA / Hibernate（Repository 也是 DAO 思想）

都体现了 DAO 的设计理念。

简单示例

// DAO 接口
public interface UserDao {
    User findById(Long id);
}

// DAO 实现
@Repository
public class UserDaoImpl implements UserDao {
    public User findById(Long id) {
        // JDBC / MyBatis 操作
    }
}

// Service 使用
@Service
public class UserService {
    @Autowired
    private UserDao userDao;
}

总结一句话

使用 Java DAO 层，是为了把“数据访问”从“业务逻辑”中解耦出来，使系统更清晰、可维护、可测试、可扩展。

如果你愿意，我也可以讲：

• DAO 和 Repository 的区别
• 现在是否“还需要”手写 DAO
• MyBatis Mapper 算不算 DAO