PHP DAL核心目标是解耦业务与数据操作，通过统一连接管理、实体映射+查询构建器、仓储模式、事务分层及健壮性细节提升可维护性、可测试性与扩展性。
PHP 数据库访问层（DAL）的核心目标是解耦业务逻辑与数据操作细节，兼顾可维护性、可测试性和扩展性。不建议直接在控制器或服务中拼 SQL 或调用 PDO 原生方法，而应通过分层抽象把“怎么查”和“查什么”分开。
统一入口 + 驱动抽象
定义一个基础数据库连接管理器（如 Database 类），封装连接池、配置加载、驱动切换（MySQLi / PDO / PostgreSQL）。所有具体操作都通过它获取连接实例，避免多处 new PDO。驱动层用接口（如 ConnectionInterface）约束行为，便于未来替换或 mock 测试。
- 配置中心化：数据库地址、用户名、超时、字符集等从环境变量或配置文件加载，不硬编码
- 支持读写分离：连接管理器根据查询类型（SELECT vs INSERT/UPDATE）自动路由到从库或主库
- 连接异常自动重试（限于非事务场景）和断线重连机制可在此层实现
实体映射 + 查询构建器
用轻量级实体类（DTO 或 Active Record 变体）承载数据结构，配合查询构建器（Query Builder）生成安全 SQL。不推荐全 ORM（如 Doctrine ORM），除非项目规模大、关系复杂；中小项目用 Builder + 手动映射更可控。
- 实体类只含属性和 getter/setter，不包含数据库操作逻辑
- Builder 提供链式方法（select()、where()、orderBy()），最终生成参数化 SQL，杜绝拼接风险
- 支持原生 SQL 查询入口，但需显式标记（如 rawQuery()），并强制绑定参数
仓储模式（Repository）隔离数据源细节
为每个核心业务实体（如 User、Order）定义对应仓储接口（UserRepositoryInterface）及其实现（DbUserRepository）。上层服务只依赖接口，DAL 变更不影响业务逻辑。
立即学习“PHP免费学习笔记（深入）”；
- 仓储方法命名体现业务意图（如 findByEmailAndActive()），而非技术动作（避免 selectByWhere()）
- 复杂查询可引入 Specification 模式或 Criteria 对象，提升复用性
- 支持缓存装饰器（如 CachedUserRepository），在不修改原有实现前提下叠加缓存逻辑
事务与领域操作边界清晰
事务控制不应放在仓储内，而由应用服务（Application Service）或用例层显式开启、提交或回滚。仓储方法默认是非事务的原子操作；需要跨多个仓储的一致性操作，由上层协调。
- 避免在仓储方法里调用 $pdo->beginTransaction() —— 违反单一职责
- 提供 TransactionManager 工具类，封装 begin/commit/rollback 和嵌套事务处理（如保存点）
- 领域事件发布（如用户注册成功后发消息）应在事务提交后触发，可用“事务后钩子”或异步队列解耦
不复杂但容易忽略：日志记录 SQL 执行时间与参数、敏感字段自动脱敏、批量操作的内存控制（如分批 fetch）、以及单元测试时用内存 SQLite 替换真实数据库——这些细节决定了 DAL 在实际项目中的健壮程度。
