По какому шаблону вы должны следовать для «зависимостей внутри зависимостей» в .NET Core?

Question

Рассмотрим следующее:

    public void ConfigureServices(IServiceCollection services)
    {
        ...
        services.AddSingleton<ILogger, Logger>();
        ...
    }

Так что я, очевидно, хочу, чтобы класс ведения журнала в моих методах контроллера, как показано, но у меня также есть много других компонентов, которые будут для них общими - и все эти компоненты захотят иметь ссылки на мои регистратор. В конце концов, это синглтон (который, я думаю, может быть анти-паттерном, но в любом случае).

Как правильно передавать «зависимости внутри зависимостей» в методе ConfigureServices? Я мог бы сделать что-то вроде этого, я думаю:

    public void ConfigureServices(IServiceCollection services)
    {
        Logger l = new Logger();
        services.AddSingleton<ILogger, Logger>((provider) =>
        {
            return l;
        });
        services.AddScoped<IFoo, Foo>((provider) =>
        {
            return new Foo(l);
        });
        ...
    }

Я мог бы сделать что-то подобное! Но это выглядит и похоже на взломать. Я уверен, что не должен разрешать / создавать реальные конкретные конструкции в моем методе ConfigureServices, как это, но я не знаю, как сказать моему конструктору Foo (как и методы моего контроллера) зависеть от ILogger.

Каков предполагаемый механизм для этого - или я должен придерживаться совершенно другой схемы?

Answer 1

Из того, что я могу сказать, нет никаких зависимостей внутри ваших зависимостей каким-либо "странным" способом ...

Все, что вам нужно сделать, это зарегистрировать реализацию для каждой службы следующим образом:

services.AddSingleton<ILogger, Logger>();

Когда эти строки выполняются, вы можете «запросить» ILogger в определении конструктора, и инфраструктура будет обрабатывать создание экземпляров (или нет, в зависимости от объема службы и т. Д.) И передачу ссылки на ваши вызовы.

Это означает, что если ваш IFoo «запрашивает» ILogger в одном из его конструкторов, вам не нужно делать что-то хитрое для его решения, если вы регистрируете поставщика услуг IFoo после вашего поставщика ILogger. Ниже приведен простой пример на лету, когда реализации Foo запрашивают ILogger в конструкторе

public class Foo : IFoo
{
    private readonly ILogger<Foo> _logger;

    public Foo(ILogger<Foo> logger)
    {
        _logger = logger;
    }

    public Task WriteMessage(string message)
    {
        _logger.LogInformation("Foo.WriteMessage called. Message:{MESSAGE}", message);

        return Task.FromResult(0);
    }
}