Question

在学习Unity（C＃中的DI框架）的过程中，我遇到了一个类有一个setter注入ClassB的情况

class ClassA : IClassA
{
...
    [Dependency]
    public IClassB ClassB
    {
        get { return _classB; }
        set
        {
            if (value == null) throw new ArgumentNullException("value");
            _classB = value;
        }
    }

，另一个有ClassA的构造函数注入

class ClassB : IClassB
{
...
    [InjectionConstructor]
    public ClassB(IClassA classA)
    {
        _classA = classA;
    }
}

我无法在容器中正确解析这两个类。

        var container = new UnityContainer();
        container.RegisterType<IClassB, ClassB>();
        container.RegisterType<IClassA, ClassA>();
        IClassA classA = new ClassA();
        var instance = container.Resolve<ClassA>();
        instance.DoSomethingFromClassB();

        log.Info("Constructor Injection");
        var instanceB = container.Resolve<ClassB>();
        instanceB.DoSomethingFromClassA();

这给了我一个堆栈溢出异常

我尝试了解决这个问题的不同顺序，但它似乎没有用。

我这是可行的还是我只是在浪费时间。这里到底发生了什么。

Answer 1

像Unity这样的DI框架的工作方式是，当你调用它们来实例化一个类时，它们会递归地实例化传递给该类的构造函数（或由属性设置）的所有类。这些类遵循相同的功能，因此您可以看到您是如何创建无限循环递归的。当Unity需要B时需要B和B时，它如何构建A？两者都无法构建。

在大多数DI框架中，您无法解析共同依赖的类。 这是一个糟糕的设计模式AKA代码气味。在经典意义上，如果ClassA需要了解ClassB，而ClassB作为回报需要知道关于ClassA，那么现实是他们分享了关注点，应该合并为一个班级ClassC。由于在这种情况下不存在任何关注点分离，因此在2个单独的类中将它们分开是没有任何好处的。

Unity之类的DI用于推广控制反转的模式，仅当类具有单向依赖性（不需要彼此了解）时才有效。

Answer 2

我同意@Haney 这是代码味道，但技术上可行......

只需通过Lazy<T>更改其中一个引用类型即可解析。然后它实际上不会解析该类型，直到使用它将打破无限递归循环。

即

class ClassB : IClassB
{
...
    [InjectionConstructor]
    public ClassB(Lazy<IClassA> classA)
    {
        _classA = classA;
    }
}

Unity解决循环依赖

2 个答案: