存储库中的循环依赖性”；关于持久性”；事件

本文关键字：持久性 事件 依赖性 循环 存储 | 更新日期: 2023-09-27 17:58:34

我有一种业务逻辑，当某些对象被持久化（更新或插入）到数据库时，它会执行一些事件。这些事件都是一个类本身，实现一个存储库，由DI容器解决。

工作流程是这样的：

服务A（存储库服务）在实体上运行持久化命令。在持久化之后，执行操作。但问题来了——很常见的是，操作本身想要使用同一个存储库来插入或更新另一个相同类型的实体，这会导致循环依赖。

问题是，循环依赖是由一种递归引起的，但实际上需要递归。

示例代码如下所示：

public interface IOnPersistAction {
    void Execute();
}
public class ServiceA {
    private readonly List<IOnPersistAction> actions;
    public ServiceA(List<IOnPersistAction> actions) {
        this.actions = actions;
    }
    public void PersistEntity(IEntity entity) {
        /* some persisting logic */
        foreach(var action in actions) {
            action.Execute();
        }
    }
}
public class ConcreteAction : IOnPersistAction {

    public ConcreteAction(RepositoryService repositoryService) {
        /* ... */
    }
    public void Execute() {
    }
}

很明显，这个结构是无法解析的，因为ConcreteActions依赖于RepositoryService（有充分的理由，该类可能会保留另一个实体，然后应该再次触发另一实体的操作）。

现在我正在将RepositoryService传递给Execute方法，这在某种程度上解决了DI问题，但IMHO这不是正确的解决方案。

应该使用什么设计模式或任何其他魔术来解决这种递归/循环依赖关系

存储库中的循环依赖性”；关于持久性”；事件

我假设您可以描述递归何时停止。换句话说，在某个时刻，您触发了另一个递归循环，而不应该触发。在代码中添加该条件（过滤器，如果，不管怎样）。它可以在Persist实体方法中，也可以在Concrete操作本身中，或者在我们目前没有看到的其他地方。

递归应该有一个基本情况。如果没有这一点，你的递归循环将永远继续下去。

添加您的基本案例。

相关文章：