存储库“on-persist”事件中的循环依赖关系

时间:2014-04-15 09:23:15

标签: c# entity-framework design-patterns dependency-injection

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

工作流程是这样的:

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

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

示例代码如下所示:

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问题,但恕我直言,这不是正确的解决方案。

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

1 个答案:

答案 0 :(得分:0)

我假设你可以描述递归应该停止的时间。换句话说,在某些时候,当你不应该触发另一个递归循环时。在代码中添加该条件(filter,if,whatever)。它可以是Persist-entity-method,也可以是Concrete-action本身,或者我们目前没有看到的其他地方。

递归应该有base case。如果没有这个,你的递归循环将永远持续下去。

添加你的基础案例。