DAO层应职责单一、可测试、易扩展，聚焦数据操作与业务逻辑分离；通过接口与实现分离、动词命名、实体参数、统一返回值、自定义异常、事务交由Service管理、限制手写SQL、泛型基类及敏感字段过滤等实践保障质量。
Java中级项目中，DAO层应聚焦职责单一、可测试、易扩展，避免与业务逻辑或SQL细节过度耦合。核心是把“数据怎么查”和“业务要什么”分开。
接口与实现分离，面向接口编程
每个实体对应一个DAO接口（如UserDao），定义增删改查方法；实现类（如JdbcUserDao或MybatisUserDao）只负责具体数据操作。这样便于后期切换ORM框架或加缓存代理。
- 接口方法名用动词前缀（save、findById、findAllByStatus），不暴露底层技术（比如别叫executeQueryById）
- 参数尽量用实体对象或封装的查询条件类（如UserQuery），避免一堆String/int参数堆砌
- 返回值统一用实体类或List
，不返回ResultSet、Map或JSONArray
统一异常处理，屏蔽底层差异
DAO层不抛出SQLException或MyBatis的PersistenceException，而是转为自定义运行时异常（如DataAccessException）。上层无需关心是JDBC超时还是MySQL主键冲突。
- 在DAO实现类中用try-catch包裹数据操作，对不同底层异常做语义化转换
- 日志记录原始异常堆栈，但对外只抛出带业务含义的消息（如“用户ID重复，插入失败”）
- 事务边界通常不在DAO内控制，交给Service层的@Transactional管理
支持简单动态查询，但不写复杂SQL
中级项目不必强求完全脱离SQL，但应限制手写SQL的范围。优先使用ORM的条件构造能力（如MyBatis-Plus的QueryWrapper、JPA的Criteria API），复杂报表类查询再单独写Mapper XML或@Select注解。
- 基础CRUD由通用DAO（如BaseDao
）提供，子类复用 - 多表关联、分页、排序等通过参数对象传递条件，DAO内部组装，不拼接SQL字符串
- 敏感字段（如密码、手机号）在DAO层做脱敏或过滤，不在返回结果中暴露
引入泛型与模板方法，减少样板代码
用泛型抽象通用操作，比如BaseDao
- 泛型基类提供默认实现，关键方法允许子类重写（如getTableName()）
- 避免在DAO里做DTO转换——那是Assembler或Converter的事
- 单元测试时可用内存数据库（H2）+ Mock DAO接口，不依赖真实数据库
