java DAO为何要抽象

在 Java 开发中，DAO（Data Access Object）之所以要“抽象”，本质目的不是为了炫技，而是为了解耦、可维护、可测试、可扩展。下面从几个关键角度说明。

一、DAO 抽象的核心原因

1️⃣ 隔离业务逻辑与数据访问细节

DAO 的作用是：让业务层不关心“数据从哪里来、怎么存”。

没有抽象时：

// Service 里直接写 SQL
Connection conn = dataSource.getConnection();
PreparedStatement ps = conn.prepareStatement("SELECT * FROM user WHERE id = ?");

问题：

• 业务代码依赖数据库
• 换数据库（MySQL → Oracle）要改业务代码
• 难以单元测试

✅ 抽象后：

User user = userDao.findById(1);

业务层只关心“取用户”，不关心 SQL。

2️⃣ 面向接口编程（多态 & 可替换）

DAO 通常被抽象成接口：

public interface UserDao {
    User findById(Integer id);
    void save(User user);
}

实现可以是：

• JDBC
• MyBatis
• JPA
• 内存实现（测试用）

UserDao dao = new JdbcUserDao();
UserDao dao = new MyBatisUserDao();

好处：

• 不修改 Service 代码即可切换实现
• 符合依赖倒置原则（DIP）

3️⃣ 提高可测试性（Testability）

抽象 DAO 后，可以轻松使用 Mock：

UserDao mockDao = Mockito.mock(UserDao.class);
when(mockDao.findById(1)).thenReturn(new User(1, "Tom"));

UserService service = new UserService(mockDao);

如果没有抽象：

• 测试必须连真实数据库
• 测试慢、不稳定

4️⃣ 统一数据访问规范

抽象 DAO 可以统一方法命名和行为：

UserDao
OrderDao
ProductDao

统一风格：

• findById
• save
• delete
• listAll

避免：

• 有人写 getUser
• 有人写 queryUserById

5️⃣ 便于统一事务与异常处理

在 DAO 抽象层可以统一：

• 事务控制
• 异常转换（SQLException → 自定义异常）

try {
    // DAO 操作
} catch (SQLException e) {
    throw new DataAccessException("数据库错误", e);
}

业务层无需关心底层异常细节。

6️⃣ 支持未来扩展（不修改代码）

例如：

• 加缓存（Redis DAO 包装 JDBC DAO）
• 读写分离
• 分库分表

UserDao dao = new CachedUserDao(new JdbcUserDao());

二、常见 DAO 抽象方式

✅ 接口 + 实现类（最经典）

interface UserDao {}
class JdbcUserDao implements UserDao {}

✅ 泛型 BaseDao（减少重复代码）

public interface BaseDao<T, ID> {
    T findById(ID id);
    void save(T t);
}

✅ 框架封装（MyBatis / JPA）

• MyBatis Mapper 本身就是 DAO 抽象
• Spring Data JPA：JpaRepository

三、什么时候“不必过度抽象”

DAO 抽象不是银弹：

• 超小项目
• 一次性脚本
• 原型验证

可以：

• 直接用 MyBatis Mapper
• 不强行写接口层

四、一句话总结

Java DAO 抽象，是为了让“业务不知道数据怎么存”，从而做到解耦、可替换、可测试、可维护。

如果你愿意，我也可以结合 Spring / MyBatis / JPA 给你一个具体的 DAO 抽象示例。