Question

我有一个大班级。当我的应用程序启动时，我初始化UnityContainer对象并进行配置。之后，我总是将它通过构造函数传递给层次结构中的另一个类。像这样：

Unity容器将这些类作为注册：IClassA，IClassB，IClassC，IClassD

接口的所有具体实现都具有带IUnityContainer参数的构造函数。例如，

    public class ClassA : IClassA
    {

        public ClassA(IUnityContainer unityContainer)
        {
        }
    }

因此，每当我创建某个类的新实例时，我必须传递IUnityContainer的对象。

我可以减少传递IUnityContainer对象作为构造函数参数的数量吗？也许通过使用Dependency属性？

Answer 1

是的，你应该减少它。

你应该把它减少到0。

像这样使用DI容器是一种不好的做法。不要将DI容器当作神奇的超级工厂。

您应该只使用容器，以便更轻松地在组合根撰写应用程序：read this

您的代码不应该知道它是由DI容器组成的，容器只是一种技术，而DI是一种技术。您也应该能够在没有容器的情况下编写应用程序。

那么，你如何减少它？像这样：

public class ClassA : IClassA
{
    public ClassA()
    {
    }
}

然后，如果你的ClassA需要某些东西（依赖项，接口），那么你应该通过构造函数注入它。例如。

public class ClassA : IClassA
{
    private readonly IComponent _component;        

    public ClassA(IComponent component)
    {
        _component = component;
    }
}

您也可以使用其他注射模式：属性注入，方法注入，环境背景。

如果您使用类似问题的容器，则隐藏实际类的所有依赖项。你无法弄清楚实际的类需要工作什么，因为它将使用容器来解决特定的问题。它完全取决于依赖注入，因为你没有注入依赖关系，你只是注入一个通用工厂（你可以要求任何东西）这是非常危险的，并且大大增加了复杂性。

我强烈推荐这本书：Dependency Injection in .NET - Mark Seemann

Answer 2

您正在做的是滥用容器作为ServiceLocator。这被视为anti-pattern in modern application architecture。

使用适当的依赖注入。 Martin Fowler给出good introduction on the pattern。

马克·西曼（Mark Seemann）写了一本非常好的书，名为Dependency Injection in .NET。

正如@PeterPorfy已经指出组合根的概念很重要。您在那里注册了与容器的所有依赖关系，然后通过解析应用程序或服务的根对象来启动。

您永远不会将容器交给组合根之外的类！

如何通过构造函数减少传递IUnityContainer对象的数量？

2 个答案: