仅在应用程序启动时使用DI容器？ [英] Only use a DI-container at the application start?

问题描述

通常，我将在c＃中使用依赖注入容器（统一），例如以下示例：

normally, I'll use a dependency injection container (unity) in c# like this example:

class SomeClass
{
    private readonly ILogger _logger;

    public SomeClass()
    {
        _logger = DependencyContainer.Resolve<ILogger>();
    }

    public void DoSomething()
    {
        var someOtherClass = DependencyContainer.Resolve<...>();
        someOtherClass().whatElseEver();
    }
}

昨天，我读了一些有关正确依赖的文章用di容器注射。在此之后，我知道我的榜样是完全不好的。这不是依赖注入，这就像服务定位器一样。

Yesterday, I've read some articles about correct dependency injection with a di container. After this, I know that my example is totally bad. This is not dependency injection this is just something like a service locator.

好的，如何解决这个问题？我认为使用构造函数注入可以轻松解决此问题：

Okay, how to solve this? I think with constructor injection you can solve this problem easily:

class SomeClass
{
    private readonly ILogger _logger;
    private readonly ISomeOtherClass _someOtherClass;

    public SomeClass(ILogger logger, ISomeOtherClass someOtherClass)
    {
        _logger = logger;
        _someOtherClass = someOtherClass;
    }

    public void DoSomething()
    {
        _someOtherClass().whatElseEver();
    }
}

现在我已经正确实现了依赖注入原理。
但是如何连接所有这些依赖项？我有一个呼叫者类，它可以解决 SomeClass类的所有要求的十进制：

Now I have the correct implementation of the dependency injection principle. But how to wire up all these dependencies? I have a caller class which resolve all the required decencies of the class "SomeClass":

class SomeClassCaller
{
    public void DoSomething()
    {
        var logger = DependencyContainer.Resolve<ILogger>();
        var someOtherClass = DependencyContainer.Resolve<...>();

        var someClass = new SomeClass(logger, someOtherClass);
        someClass.DoSomething();
    }
}

但是此示例仍将依赖项容器用作服务定位器，这很糟糕。在几乎所有与此相关的文章中，我都读到，仅在应用程序的根/入口点使用依赖容器是正确的吗？

But this example still use a dependency container as a service locator, which is bad. In nearly every article about this, I've read, that the dependency container should only be used, at the application root/entry points, is this correct?

，没有类可以像记录程序那样，通过服务定位器即时解决某些依赖性。我必须通过构造函数将ILogger注入几乎每个类中，以避免出现此问题，对吗？这样的感觉真的很糟糕，如果我将ILogger大概通过10个类带入每个构造函数中，不是吗？

That means, no class should have the ability the resolve some dependencies with a "service locator" on the fly, like the logger. I've to inject the ILogger into nearly every class through the constructor, to avoid this problem, correct? This way feels really bad, if I take the ILogger through maybe 10 classes into every constructor, isn't it?

因此，我只需要使用依赖项容器，如果我有一个复杂的依赖图？

So, I've to use a dependencies container only, if I've a complex dependencie graph?

有人可以给我一个例子，如果您使用依赖容器，那么它仅位于应用程序的根目录？

Can someone give me an example how it looks like, if you use a dependency container, only at the root of an application?

推荐答案

如果 SomeClassCaller 需要 SomeClass ，注入它：

public class SomeClassCaller
{
    private readonly SomeClass someClass;

    public SomeClassCaller(SomeClass someClass)
    {
        this.someClass = someClass;
    }

    public void DoSomething()
    {
        this.someClass.DoSomething();
    }
}

这是具体依赖性。但是，通常，您可以让 SomeClass 实现一个接口，然后将该接口注入到 SomeClassCaller 中，而不是具体的。

This is an example of a Concrete Dependency. Commonly, though, you could let SomeClass implement an interface, and then inject that interface into SomeClassCaller, instead of the concrete class.

在组合根中您可以连接对象图：

var scc = new SomeClassCaller(
    new SomeClass(
        new MyLogger(),
        new SomeOtherClass()));

您不需要DI容器来执行此操作，但是您可以使用一个。

You don't need a DI Container to do this, but you can use one if you like.

这篇关于仅在应用程序启动时使用DI容器？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！