使用HttpClientFactory的哪种方式更好？

Question

我正在使用ASP.NET核心开发一个web服务，我需要做http请求。我读了很多关于HttpClient的文章，我知道我必须用HttpClientfactory代替。我将把http请求调用封装到我的自定义类中。

我期望有相当多的客户端请求，并且我试图理解哪种方式在性能上更好(附了两个例子)。

我更喜欢第二种方式，因为我可以将它应用到静态类中，但我不确定性能。

// IHttpClientFactory registration
public void ConfigureServices(IServiceCollection services)
{
 services.AddHttpClient();
}


// my first way (dependency injection into custom class)
public class CustomClass
{
  private readonly IHttpClientFactory _clientFactory;
  public CustomClass(IHttpClientFactory clientFactory)
   {
     _clientFactory = clientFactory;
   }
}

// my second way
var serviceProvider = new ServiceCollection().AddHttpClient().BuildServiceProvider();
var httpClientFactory = serviceProvider.GetService<IHttpClientFactory>();
var client = httpClientFactory.CreateClient();

Answer 1

你的第一条路是对的。

public class CustomClass
{
  private readonly IHttpClientFactory _clientFactory;
  public CustomClass(IHttpClientFactory clientFactory)
   {
     _clientFactory = clientFactory;
   }
}

通过这种方式，您可以允许依赖注入来解决IHttpClientFactory服务，而无需您的努力。DI容器存在于应用程序的整个生命周期中，并处理各种服务的创建--例如，它可以在请求时提供保留工厂实例。圆滑，快速，安全。服务的配置只发生一次--在应用程序启动时。

第二条路

第二种方法是分配大量不必要的新对象(这些对象消耗更多的RAM)，就像您所说的那样--“相对大量的客户端请求”。这是因为您基本上是在做IoC容器所能做的事情，但是是手动的，并且有明显的开销。假设您不会在单例中使用此代码，而是在一个作用域或临时服务中使用(请参阅差异这里)，那么对于每个传入的请求，您将创建服务集合、添加所需的服务、创建服务提供者、尝试解析工厂并最终创建一个HttpClient。

在第一种方式中，您只执行最后两个步骤--解析工厂并创建新的HttpClient。所有其他都由DI来处理。

面包店

想象一下拥有一家面包店。每天都有数以百计的客户经过。他们都要求熟食--你那著名的布朗尼。为了生产出足够多的蛋糕，你想出了两种生产方法：

路#1

在开面包店之前，你先开始新的一天，然后做好安排--你洗碗、加热烤箱、准备碗和面团的配料等等。到了开门的时候，你就准备好了，你可以马上开始制作大量的巧克力饼，因为你的面包店里的所有东西都在你的手边。

道路2

你开始你的一天来面包店的时候开门。你不做任何准备。只有当一个客户出现时，你开始加热烤箱，收集碗和配料-所有这些，你可以做一个单一的布朗尼。当你完成，你把所有的东西放回它的位置，关闭烤箱，即使当你可以看到有一个长队就在你的面包店。当下一个客户端接近时，您将再次启动该过程。

结论

我希望你能看到第一种方式的更好的表现。当然，面包店例子的第二种方式是过分夸张的，但这只是为了显示更大的对比。

单独创建服务提供商并不是件坏事。您只需要有充分的理由就可以这样做，例如数据库种子或单元/集成测试。