Java DAO层规范要求接口与实现分离、命名统一、职责清晰：DAO定义为接口（如UserDAO），实现类加Impl后缀（UserDAOImpl）；方法命名遵循get/list/count/save/delete/update约定；使用DO/DTO/VO区分数据对象；禁止裸写资源操作，异常需转换为业务异常；事务由Service层管理。

Java 中规范 DAO 层的数据库访问代码结构，核心是做到职责清晰、接口稳定、实现可替换、命名统一。不是写完能查数据就行，而是让后续维护、测试、迁移数据库时少踩坑。

DAO 接口与实现类要严格分离

DAO 必须定义为接口，不能直接写实现类。接口名用业务语义命名（如 UserDAO、OrderDAO），实现类统一加 Impl 后缀（如 UserDAOImpl）。这样 Service 层只依赖接口，切换 MyBatis 为 JDBC 或迁移到 Redis 时，只需替换 Impl 类，上层完全无感。

• 接口中方法命名遵循约定：查询单个用 get 开头（getUserById），批量查用 list（listActiveUsers），统计用 count，新增用 save 或 insert，删除用 delete 或 remove，更新用 update
• 避免在接口里暴露技术细节，比如不出现 executeQuery、getConnection 这类 JDBC 方法
• 所有方法参数和返回值都使用 POJO（如 UserDO、OrderDTO），不直接传 ResultSet 或 Connection

实体类与数据对象类型要明确区分

不同场景用不同后缀的类，不能混用：

Java Maven Common

Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。

下载

• xxxDO：Data Object，与数据库表一一对应，字段名、类型、主键策略都严格对齐，通常由代码生成器产出
• xxxDTO：Data Transfer Object，用于跨层或跨系统传输，字段可聚合、裁剪、脱敏，比如把 UserDO + ProfileDO 合成 UserDetailDTO
• xxxVO：View Object，面向前端展示，字段名可带 UI 语义（如 createTimeStr、statusLabel），不参与持久化
• 禁止出现 xxxPOJO 这种泛化命名，它掩盖了实际用途，也违反分层契约

DAO 实现内部要封装资源与异常

不管用 JDBC、MyBatis 还是 JPA，DAO 实现类里不能裸写连接获取、手动 close、try-catch SQLException 塞满日志：

立即学习“Java免费学习笔记（深入）”；

• 数据库连接必须通过 DataSource 获取，不硬编码 URL/username/password
• 使用 try-with-resources 自动释放 Statement/ResultSet，或交由框架（如 Spring 的 JdbcTemplate、MyBatis SqlSession）管理生命周期
• 原始 SQL 异常（SQLException）要转换为自定义业务异常（如 DataAccessException），不向上抛出底层驱动错误
• 事务控制不在 DAO 层做，留给 Service 层统一声明式管理（@Transactional）

命名与常量要符合通用规范

DAO 层也是 Java 项目的一部分，需遵守团队基础规范：

• DAO 接口方法参数、变量全部小驼峰（userId、orderStatus），不拼写缩写（不用 usrId）
• SQL 中的表名、字段名若映射到 Java 属性，保持语义一致（数据库 user_name → Java userName），用 ORM 注解或 resultMap 显式配置
• 固定值不用魔法数字或字符串，比如状态码定义为枚举（OrderStatusEnum），SQL 模板抽成 public static final String 常量
• 布尔字段在 DO 中不加 is 前缀（用 enabled，不用 isEnabled），防止 Jackson 或 MyBatis 反射失败