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 项目审查工作流的通用输入处理。当 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 塞满日志:
- 数据库连接必须通过 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 反射失败
Java免费学习笔记:立即使用
解锁 Java 大师之旅:从入门到精通的终极指南










