4.4 数据访问对象模式

数据访问对象模式（DAO，Data Access Object）把数据访问逻辑封装在一个接口背后，让业务层不再直接面对 SQL、JDBC、连接、ORM 这些持久化细节。业务代码只调用 userDao.findById(42)，至于背后是 MySQL、内存还是 MongoDB，它一概不知，也不需要知道。

下面的实验切换底层数据源（MySQL / 内存 / Mongo），注意业务层调用 findById() 的那行代码始终不变。

接口与实现分离

interface UserDao {                         // 业务层只依赖这个接口
    void save(User u);
    Optional<User> findById(int id);
    void delete(int id);
}

class JdbcUserDao implements UserDao { /* 参数化 SQL */ }
class InMemoryUserDao implements UserDao { /* 测试用 HashMap */ }

这种分离带来两个关键好处：

• 可替换数据源：换实现不影响业务代码——上线用 JDBC，测试用内存实现。

• 可测试性：业务逻辑可以注入内存 DAO，脱离真实数据库进行单元测试，又快又稳定。

下面的实验是一个 DAO 增删改查台，让你通过 DAO 的标准方法操作数据，而看不到任何 SQL。

DAO、Repository 与本项目

你可能听过 Repository 模式，它和 DAO 很像，常被混用。一个常见区分是：DAO 更贴近“表/数据源”的 CRUD，Repository 更贴近“领域对象集合”的抽象。但在实践中，二者的核心都是把持久化细节挡在业务逻辑之外。

值得一提的是，本教程所在的 Leaflet 项目，其后端设计正是 DAO 思想的体现：技术文档明确要求不使用 ORM，而是“把查询集中放在 repository/service 层，不在 route 中散落 SQL”，并用参数化查询防注入。这正是 DAO 模式在真实工程里的落地——用一层清晰的数据访问抽象，换取可维护、可测试、可演进。