ILogger and DependencyInjection Architecture in ASP.NET Core

Question

My team is pretty big on DependencyInjection. Personally I'm a bit too far out of the loop lately to really judge the correct usage of this. But I do see more and more code like this:

public AuthenticationApi(ILogger<AuthenticationApi> logger,
                         HttpClient httpClient,
                         IJsonConverter jsonConverter,
                         IDtoConverter dtoConverter) : base(logger, httpClient, jsonConverter)
{
    _dtoConverter = dtoConverter;
}

And then this multiplies across the code, where half of our code is just calling constructors with endless DependencyInjection related stuff. My team told me, that's the way of .NET Core. And yes, answers like this confirm it:

ILogger and DependencyInjection in ASP.NET Core 2+

And discussions like that would be more along my gut feeling that things like logging, etc. should just be transparent and not handled in endless DependencyInjection constructor chains:

https://softwareengineering.stackexchange.com/questions/371722/criticism-and-disadvantages-of-dependency-injection

In another place (unfortunately I can't find the article anymore), I read that this constructor issues are mainly a result of badly implemented Service Factories.

Thoughts on the topic are appreciated.

Based on the discussion below, this is the baseclass and uses both the Logger and the HttpClient:

internal class ApiBase
{
    private readonly ILogger _logger;
    private readonly IJsonConverter _jsonConverter;
    private readonly HttpClient _httpClient;

    public ApiBase(ILogger logger, HttpClient httpClient, IJsonConverter jsonConverter)
    {
        _logger = logger;
        _jsonConverter = jsonConverter;
        _httpClient = httpClient;
    }

    protected async Task<T> GetAsync<T>(string path, HttpContent content = null)
    {
        _logger.LogDebug($"Sending GET request to {path}");

        using (var request = new HttpRequestMessage(HttpMethod.Get, path))
        {
            request.Content = content;

            using (var response = await _httpClient.SendAsync(request).ConfigureAwait(false))
            {
                if (response.IsSuccessStatusCode)
                {
                    _logger.LogDebug($"GET request to {path} was successful.");

                    var responseContent = await response.Content.ReadAsStringAsync().ConfigureAwait(false);

                    var deserializeResponseContent = _jsonConverter.Deserialize<T>(responseContent);

                    return deserializeResponseContent;
                }

                var message = GetErrorMessage("GET", path, response);
                _logger.LogError(message);
                throw new HttpRequestException(message);
            }
        }
    }

Answer 1

And then this multiplies across the code, where half of our code is just calling constructors with endless DependencyInjection related stuff. My team told me, that's the way of .NET Core.

Yes and no. Constructor injection of dependencies is a standard method in .NET Core to organize your dependencies. And it works great.

What is non-standard is your base class and the fact that you have those constructor chains where half your parameters aren't actually needed, but just go into the base class constructor. I will bet that this base class does not actually do anything worthwhile.

Remove the base class. See what you still need for every controller. Only inject that. These base classes and their own constructors are a great way to obfuscate what the actual dependencies are. Because now suddenly every class needs an IJsonConverter, must be pretty important. But you will have a hard time figuring out who actually makes use of the base class functionality that uses it. So of your 20 classes derived of the base, who really needs it, and who only requires it to make the compiler happy?

My advice is to remove the base class. Inject into each controller what they need, not more and not less. So you can actually see the dependencies. If you have common functionality in that base class, it can probably be a static method somewhere that gets those fields as parameters. Or maybe it can be a service of it's own that is injected where needed. But only where needed.