实例化具体的 HttpClient 实例是否是 .NET 中依赖注入的错误使用？

Question

我正在尝试遵循最佳实践来创建松散耦合的代码，但我仍然需要对依赖注入有更深入的了解。

所以我想知道这段代码是否尊重这个概念，因为我仍在属性中实例化一个类。我在这里谈论的是

HttpClient

。

谁能告诉我是否很好地利用了依赖注入？或者针对

HttpClient

的具体实例进行编程是否会产生紧密耦合？

程序.cs：

builder.Services.AddHttpClient("AuthService", client =>
{
    client.BaseAddress = new Uri(builder.Configuration.GetValue<string>("Address")!);
}).ConfigurePrimaryHttpMessageHandler(() => new HttpClientHandler
{
    ServerCertificateCustomValidationCallback = (_, _, _, _) => true,
    AllowAutoRedirect = false,
    UseCookies = true
});

Auth.cs

public class Auth(IHttpClientFactory httpClientFactory) 
{
    ...
    private HttpClient client = httpClientFactory.CreateClient("Auth");
    ...
    public async Task<Result<Uri>> GetStuff()
    {
        try
        {
            using var response = await client.GetAsync("www.example.com");

            if (response.StatusCode == HttpStatusCode.OK)
              return Result<Uri>.Success(cachedLocation);
        }
        catch (HttpRequestException ex)
        {
            return Result<Uri>.Failure($"HTTP request failed: {ex.Message}");
        }
    }
}

Answer 1

在我们的书《依赖注入原则、实践和模式》中，Steven van Deursen 和我将依赖注入 (DI) 描述为一组模式和原则，可实现松散耦合、可测试性和其他有益的设计。 OP 的 Auth 类中使用的构造函数注入就是这样一种模式，所以我认为这是 DI 的一种情况。

DI 的另一个重要组件是

Composition Root

，它通常是程序的入口点；在这里，Program.cs。您需要在

某处

组合所有对象图，入口点通常是执行此操作的最佳位置。 OP 展示的就是我所说的

纯 DI

。我不仅认为它是一种有效的 DI 技术，而且实际上我认为它比使用 DI 容器更好，因为纯 DI 是类型安全的，而容器则不是。 所以我会做一些类似于OP中所示的事情，尽管现在我不太热衷于注入工厂。然而，这是另一天的另一个讨论。