Active Record模式，存储库模式和可测试性（在Java中）

有两件事引起了一些关注。第一个是这个报价（强调我的意思）：   [...]有没有信息系统，其中数据库逻辑仅代表整个业务逻辑的一小部分，并且模拟数据库访问会很有趣？ 您是否正在将业务逻辑放入数据库中？如果是这样：不要这样做，这将使模拟数据库非常困难。您必须将所有业务逻辑从数据库复制（并维护！）到您的模拟中，否则您的测试是无用的。 但是您如何知道模拟是否正确实现了业务逻辑？您可以为模拟编写单元测试，也可以重用数据库的单元测试（您确实拥有它们，对吗？），但这是我将不惜一切代价避免的一种方法！让我重复一遍：永远不要（不必）为模拟编写单元测试。如果您发现自己处于这种情况，请退后几步并检查设计，因为这是非常错误的。 将业务逻辑放入数据库中只会在模型与数据库之间造成不必要的耦合，并极大地增加测试层的复杂性。关注点分离在这里很关键：该模型仅关注业务逻辑，而数据库仅关注持久性，仅此而已。 这让我想到了下一个问题：为什么在域模型上需要与持久性相关的

save()

和

delete()

方法？持久性不属于域模型。 我知道，您说过这些方法将委托给一个存储库，因此域模型（希望）不包含实际的持久性逻辑。但是，它如何知道应委托给哪个存储库？ 如果要通过

save()

方法调用服务定位器，则无法将实体保存到多个存储库。您还向调用者隐藏了对存储库的依赖，我认为这是一件坏事。 要解决这些问题，可以将存储库实例传递给

save()

方法，如下所示：

public class Foo extends AbstractPersistentObject {
    public void saveTo(IFooRepository repository) {
        repository.save(this);
    }
}

但是这样的方法意味着调用者已经有一个存储库实例，因此他最好直接在存储库上调用“ 0”方法。域模型上的任何持久性方法都将过时。 也许我过分简化了您的问题。您要达到的目标是什么？您只想要the6ѭ语法，还是要解决更大的问题？