ASP.NET 內核中的 ILogger 和依賴注入架構

Question

我的團隊非常依賴 DependencyInjection。 就個人而言，我最近有點離題太遠了，無法真正判斷這個的正確用法。 但我確實看到越來越多這樣的代碼：

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

然后這會在代碼中成倍增加，其中一半的代碼只是調用構造函數，其中包含無窮無盡的 DependencyInjection 相關內容。 我的團隊告訴我，這就是 .NET Core 的方式。 是的，這樣的答案證實了這一點：

ASP.NET Core 2+ 中的 ILogger 和 DependencyInjection

像這樣的討論更符合我的直覺，比如日志記錄等應該是透明的，而不是在無休止的 DependencyInjection 構造函數鏈中處理：

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

在另一個地方（不幸的是，我再也找不到這篇文章了），我讀到這個構造函數問題主要是由於服務工廠實現不當造成的。

對此主題的想法表示贊賞。

根據下面的討論，這是基類並同時使用 Logger 和 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

然后這會在代碼中成倍增加，其中一半的代碼只是調用構造函數，其中包含無窮無盡的 DependencyInjection 相關內容。 我的團隊告訴我，這就是 .NET Core 的方式。

是和不是。 構造函數注入依賴項是 .NET Core 中用於組織依賴項的標准方法。 而且效果很好。

非標准的是您的基本 class 以及您擁有實際上不需要一半參數的那些構造函數鏈，而只是 go 進入基本 class 構造函數的事實。 我敢打賭，這個基礎 class 實際上並沒有做任何有價值的事情。

拆下底座 class。 查看每個 controller 仍然需要什么。 只注入那個。 這些基類和它們自己的構造函數是混淆實際依賴關系的好方法。 因為現在突然間每個 class 都需要一個 IJsonConverter，一定很重要。 但是您將很難弄清楚誰真正使用了使用它的基本 class 功能。 那么在你從基礎派生的 20 個類中，誰真正需要它，誰只需要它來讓編譯器滿意？

我的建議是刪除基礎 class。 注入每個 controller 他們需要的東西，不多也不少。 所以你實際上可以看到依賴關系。 如果您在該基礎 class 中具有通用功能，則它可能是某處的 static 方法，該方法將這些字段作為參數。 或者它可以是它自己的服務，在需要的地方注入。 但只在需要的地方。