Question

我正在使用ASP.NET Core开发Web api服务，我需要执行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容器在您的应用程序的整个生命周期中一直存在，并处理各种服务的创建-例如，它keeps the factory准备在被请求时提供HttpClient的实例。光滑，迅捷，安全。服务的配置仅发生一次-在应用程序启动时。

第二种方式

第二种方式将在-如您所说-“相对大量的客户端请求” 下分配大量不必要的新对象（它们消耗更多的RAM）。那是因为您基本上正在做IoC容器会做的事情，但是要手工做，而且开销很大。假设您不会在单一实例中使用此代码，而是在有范围的服务或临时服务中使用此代码（请参见差异here），那么对于每个传入请求，您将创建服务集合，添加所需服务，创建服务提供者，然后尝试解决工厂问题并最终创建HttpClient。

用第一种方法，您只需要执行最后两个步骤-解决工厂问题并创建新的HttpClient。其他都由DI处理。

面包店

想象一下拥有一家面包店。每天都有数百位客户前来。他们都要求提供美味佳肴-您著名的布朗尼蛋糕。为了能够生产足够的蛋糕，您想出了两种生产方法：

方法1

您可以从开面包店开始新的一天并进行安排-清洁碗碟，加热烤箱，准备面团用的碗和配料等。当需要打开时，您就可以开始做很多工作了布朗尼的飞行，因为面包店里的一切都在手边。

方法2

您开始在面包店开业的那一天开始。您没有做任何准备。只有当客人出现时，您才开始加热烤箱，收集碗和食材-所有这些都可以制作一个布朗尼。完成后，将所有东西放回原处，关闭烤箱，即使看到面包店前排着长队也是如此。当下一个客户接近时-您再次开始该过程。

结论

希望您能看到第一种方法的更好性能。当然，面包店示例的第二种方式被夸大了，但这只是为了显示更大的对比。

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

哪种方法使用HttpClientFactory更好？

1 个答案:

您的第一种方法是正确的。

第二种方式

面包店

方法1

方法2

结论