DAOs中的数据一致性

Question

在Google上查找"dao数据一致性“或”数据访问层数据一致性“没有任何有用的结果。

假设我必须编写使用SQL作为数据源的DAO，假设我的模式强制执行大部分(但不是全部)业务数据(?)规则，如非空用户名等。但是，为了本例的目的，并不是不可能使用DDL检查或其他SQL机制进行检查的。

这是否意味着我的do必须确保数据的一致性，或者它们必须是“愚蠢的”，并期望调用方进行适当的检查？

使用SQL的实际示例:此模式有两个表

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)
    
);

而SQL中的一个典型事务将根据金额更新2个帐户余额，并在transfer中创建一个仅用于显示的记录(例如，列出web应用程序中的所有汇款)；如果我有DAOs，例如允许我在transfer中插入记录而不必进行实际的帐户余额更新，或者我应该只拥有与事务类似的DAO(通过使用java.sql API的connection.setAutoCommit(false)等)。甚至可以做数据库无法确保应用程序需求所指定的数据一致性的事情吗？

附注：如果我似乎想用木槌作为扳手，那是因为它是大学项目的一部分，它要求我们的学生在不使用任何花哨的新框架或API的情况下，以良好的方式去做。

Answer 1

出于我个人纯粹的实践经验(这听起来可能与其他开发人员所经历的类似)：总是将DAO方法保持为简单而愚蠢的：它们的唯一目的是从数据库(或存储/删除/更新)数据库中获取一些数据。

我不喜欢DAO中的逻辑(if条件、循环、委托给其他类等等)。要回答为什么我实际上更喜欢这种方法，首先让我解释一下我实际上做了什么，然后比较：

因此，我通常将代码划分为至少3层：

• 端点(通过web、消息传递系统等处理传入请求)-这里没有特殊的逻辑，可能是简单的验证。这一层相对来说是simple.
• Backend服务--这是所有后端逻辑都存在的地方，包括各种非平凡的检查、算法等
• DAOs--类似于“终结点”的第一层，但这次是在DB interconnection.

级别。

当然，服务层是最难实现的，但是它没有任何“外部”依赖关系，比如数据库、远程http服务等等--我们向该层输入了一些数据，它处理数据，有时通过DAOs在定义良好的和封装的点中调用DB。

这反过来又允许对服务层进行相对简单的测试(通常使用单元测试)。

现在对于DAO来说，测试这些数据的方法更复杂(如果没有真正的DB，您将如何检查查询是否正确)？因此，如果我将在DAO层介绍逻辑，我将添加两个主要问题(在我看来，可能有更多的问题)：

• --某些逻辑段将位于DAO级别，而其他逻辑段(如复杂的检查)将位于服务层。因此，它使代码更加混乱，更难理解/导航/维护/命名它。另外，如果有一天我想用其他的东西代替我的数据库，那该怎么办呢？如果我将逻辑保留在DAO中，我将不得不以某种方式重新实现这个逻辑，而如果我保持DAO简单--我只是重写查询，这样做就容易多了，而且速度快得多。
• 如何测试那些已经“找到路”到DAO层的业务逻辑？在性能方面，DAO通常需要集成测试，这比“常规”单元测试更慢、更昂贵。因此，我现在必须为DAO维护更多的集成测试，这将使我更慢的整体应用程序构建过程(测试是在构建过程中运行的)

。