DAO模式将SQL集中封装在独立类中，业务层仅调用方法名，实现数据访问与业务逻辑隔离，确保修改一处、全局生效，支持多数据库切换、Mock单元测试及精准SQL优化。
当你在接手一个已有三年的PHP项目，翻到第17个控制器里嵌着的SQL语句时，突然发现其中一条查询漏写了WHERE条件却已上线两周——这时候你就明白为什么主流PHP框架坚持用DAO模式封装数据访问了。
DAO让SQL不再散落在业务代码里
把所有数据库操作集中到独立的DAO类中，业务逻辑层只调用方法名，比如userDao->findByEmail($email)，而不是直接拼接"SELECT * FROM users WHERE email = '$email'"。这种隔离能避免SQL随业务逻辑反复复制、粘贴、改错、再复制。
一旦某张表字段重命名或索引调整，你只需修改DAO实现里的一个方法，所有调用它的控制器、服务类、命令行脚本自动生效。如果SQL散在23个PHP文件里，就得手动grep、逐个改、逐个测——漏掉一个就埋下隐患。
这一步不是“可选优化”，而是【DAO接口必须定义明确的CRUD契约，否则业务层调用将失去统一入口】。
立即学习“PHP免费学习笔记（深入）”；
换数据库不用重写业务逻辑
方法一：基于PDO抽象层实现多数据库支持
在DAO接口中定义save(User $user)，MySQL实现类用INSERT INTO users...，PostgreSQL实现类用INSERT INTO users ... RETURNING id，SQLite实现类处理AUTOINCREMENT差异——业务层完全感知不到底层变化。
方法二：通过配置切换DAO实现'db_driver' => 'pgsql' → 自动加载PgsqlUserDao；'db_driver' => 'sqlite' → 加载SqliteUserDao。只要它们都实现同一接口，控制器代码一行都不用动。
注意：Oracle和MySQL对LIMIT语法处理完全不同，DAO层屏蔽了这种差异，业务层不必写if ($driver === 'mysql') { ... } else if ($driver === 'oracle') { ... }这种污染性判断。
单元测试不再依赖真实数据库
第一步：为DAO接口编写Mock对象
用PHPUnit创建MockUserDao，让它在findById(123)时返回预设的User实例，不连接任何数据库。
第二步：注入Mock到Service类中$service = new UserService($mockUserDao); → 调用$service->promoteToAdmin(123)时，内部调用的是Mock，而非真实查询。
第三步：验证行为而非数据
断言$mockUserDao->update()被调用一次，且传入的User对象role属性已改为'admin'——这比启动MySQL容器跑一遍真实SQL快12倍，也更稳定。
没有DAO抽象层，你只能对整个Controller做集成测试，每次都要清空测试库、重置自增ID、处理外键约束——根本没法做高频回归。
SQL优化只发生在一处
当慢查询告警触发，DBA给出优化建议：“给orders表的status和created_at加联合索引，并改用覆盖索引查询”。你打开OrderDao.php，找到findPendingSince()方法，把原始SQL：SELECT * FROM orders WHERE status = ? AND created_at > ?
替换成：SELECT id, user_id, total FROM orders WHERE status = ? AND created_at > ?
这个改动立刻生效于所有调用该方法的场景：后台订单列表页、API导出接口、定时结算任务——不需要去翻找哪几个控制器写了类似SQL，也不用担心遗漏某个角落的重复实现。
这一步的关键是【DAO方法名必须语义清晰，不能叫get()或query()这种泛化命名，否则无法定位优化点】。
