0

我正在使用 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();
4

1 回答 1

2

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

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

通过这种方式，您允许依赖注入来解决IHttpClientFactory服务，而无需您付出太多努力。DI 容器存在于应用程序的整个生命周期中，并处理各种服务的创建——例如，它使工厂准备好在HttpClient请求时提供实例。时尚、快速和安全。服务的配置只发生一次 - 在应用程序启动时。

第二种方式

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

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

面包店

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

方式#1

您在开面包店之前开始新的一天并进行安排 - 您清洁盘子，预热烤箱，准备碗和面团配料等。当它打开时，您已经准备好，您可以开始制作大量的巧克力蛋糕飞，因为你面包店里的一切都在手边。

方式#2

你开始新的一天，在开门的时候来到面包店。你没有做任何准备。只有当客户出现时，您才开始加热烤箱、收集碗和配料——所有这些都是为了制作一个巧克力蛋糕。完成后，您将所有东西放回原处，关闭烤箱，即使您可以看到面包店前排起了长队。当下一个客户接近时 - 你再次开始这个过程。

结论

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

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

于 2019-07-02T17:53:08.580 回答