DAO中的数据一致性：职责划分与实现方案问询

核心问题 #

在谷歌搜索“dao data consistency”或“data access layer data consistency”未找到有效结果，现需基于SQL数据库编写DAO：

• 数据库Schema已实现多数业务规则（如用户名非空），但部分规则无法通过DDL或SQL机制校验
• 疑问：DAO是要自行保证数据一致性，还是仅做“傻瓜式”实现，把校验交给调用方？

实操场景示例 #

数据库Schema包含两张表：

create table bank_accounts
(
    accid int primary key,
    balance int not null default 0,
    check(balance >= 0)
);

create table transfer
(
    tid int primary key,
    senderaccid int not null, 
    receiveraccid int not null,
    sendercurrentbalance int not null,
    receivercurrentbalance int not null,
    amount int not null, 
    check(amount > 0),
    foreign key (senderaccid) references bank_accounts(accid),
    foreign key (receiveraccid) references bank_accounts(accid)
);

典型业务流程：根据转账金额更新两个账户余额，并向transfer表插入记录用于展示（如Web应用的转账记录列表）。

疑问：

• 应提供可单独插入transfer记录的DAO？
• 还是仅提供基于java.sql API实现事务（如connection.setAutoCommit(false)）的DAO？
• 是否需要补充数据库无法完成的校验，以保证符合应用需求的数据一致性？

注：此为大学项目，要求采用传统方式实现，不得使用新型框架或API。

1. DAO的职责边界 #

DAO核心是封装数据库访问细节，但不能完全“傻瓜式”甩锅。对于数据库没法通过DDL/SQL约束实现的规则，DAO必须承担基础数据一致性校验——这既能避免无效请求浪费数据库资源，也能保证进入持久层的数据合法。比如转账场景里，数据库没法校验“转出账户余额≥转账金额”，这个检查就得放在DAO层前置处理。

但要划清边界：DAO只负责和持久化相关的一致性校验，像单日转账限额这类业务逻辑，得放在业务层（Service）处理，别让DAO变成“万能层”。

2. 转账场景的DAO设计 #

绝对不能提供单独插入transfer记录的DAO方法——这会直接破坏数据一致性：要是调用方只插了转账记录却没更账户余额，就会出现“记录有但钱没动”的脏数据。

正确做法是：

• 提供一个包含完整转账逻辑的事务型DAO方法，在同一个事务内完成所有操作：
  1. 前置检查：转出账户余额≥转账金额、转出/转入账户不是同一个
  2. 更新转出账户余额：update bank_accounts set balance = balance - amount where accid = ?
  3. 更新转入账户余额：update bank_accounts set balance = balance + amount where accid = ?
  4. 插入transfer转账记录
• 用java.sql.Connection手动管控事务：先设setAutoCommit(false)，所有操作成功后调用commit()，一旦出异常就执行rollback()。

3. 补充数据库未覆盖的校验 #

针对数据库实现不了的规则，DAO必须补全校验，比如：

• 转账前确认转出账户余额足够
• 校验转出、转入账户不能为同一个ID
• 提前拦截非正整数的转账金额（虽然数据库有check(amount>0)，但前置检查能更早拦截非法请求）

这些校验能减少数据库异常抛出，同时保证进入数据库的数据完全符合应用预期。

4. 大学项目的实现细节 #

因为要求传统方式实现，不用框架，要注意这些点：

• 手动管理Connection生命周期，用try-with-resources或者finally块确保资源关闭
• DAO方法别私自捕获异常，把异常抛给上层处理，避免事务无法正确回滚
• 所有涉及多表修改的操作必须放在同一个事务里，保证原子性

内容的提问来源于stack exchange，提问作者Federico Bocchieri