c# - ASP.NET Core 2 中多个相同类型实例的依赖注入(inject)

Question

在ASP.NET Core 2 Web Api中，我想使用依赖注入(inject)来注入(inject)httpClientA HttpClient 的实例至 ControllerA ，和一个实例 httpClientB的HttpClient至 ControllerB .

DI 注册代码如下所示:

HttpClient httpClientA = new HttpClient();
httpClientA.BaseAddress = endPointA;
services.AddSingleton<HttpClient>(httpClientA);

HttpClient httpClientB = new HttpClient();
httpClientB.BaseAddress = endPointB;
services.AddSingleton<HttpClient>(httpClientB);

我知道我可以子类化 HttpClient为每个 Controller 制作一个独特的类型，但这不能很好地扩展。

什么是更好的方法？

更新
特别是关于 HttpClient 微软似乎在做一些事情

https://github.com/aspnet/HttpClientFactory/blob/dev/samples/HttpClientFactorySample/Program.cs#L32 - 感谢@mountain-traveller (Dylan) 指出这一点。

Answer 1

Note: This answer uses HttpClient and a HttpClientFactory as an example but easily applies to any other kind of thing. For HttpClient in particular, using the new IHttpClientFactory from Microsoft.Extensions.Http is preferred.

内置依赖注入(inject)容器不支持命名依赖注册，还有 no plans to add this at the moment .
这样做的一个原因是，对于依赖注入(inject)，没有类型安全的方法来指定您想要哪种命名实例。您肯定可以使用类似构造函数的参数属性(或属性注入(inject)的属性)之类的东西，但这将是一种不同的复杂性，可能不值得；它当然不会得到类型系统的支持，这是依赖注入(inject)工作方式的重要部分。
通常，命名依赖项表明您没有正确设计依赖项。如果您有两个相同类型的不同依赖项，那么这应该意味着它们可以互换使用。如果情况并非如此，并且其中一个有效而另一个无效，则表明您可能违反了 Liskov substitution principle .
此外，如果您查看那些确实支持命名依赖项的依赖项注入(inject)容器，您会注意到检索这些依赖项的唯一方法不是使用依赖项注入(inject)，而是 service locator pattern相反，这与 inversion of control 正好相反DI 促进。
Simple Injector，较大的依赖注入(inject)容器之一， explains their absence of named dependencies like this :

Resolving instances by a key is a feature that is deliberately left out of Simple Injector, because it invariably leads to a design where the application tends to have numerous dependencies on the DI container itself. To resolve a keyed instance you will likely need to call directly into the Container instance and this leads to the Service Locator anti-pattern.

This doesn’t mean that resolving instances by a key is never useful. Resolving instances by a key is normally a job for a specific factory rather than the Container. This approach makes the design much cleaner, saves you from having to take numerous dependencies on the DI library and enables many scenarios that the DI container authors simply didn’t consider.

尽管如此，有时您真的想要这样的东西，并且拥有大量的子类型和单独的注册根本不可行。在这种情况下，有适当的方法来解决这个问题。
我能想到的一种特殊情况是 ASP.NET Core 在其框架代码中具有与此类似的内容:身份验证框架的命名配置选项。让我尝试快速解释这个概念(请耐心等待):
ASP.NET Core 中的身份验证堆栈支持注册多个相同类型的身份验证提供程序，例如您可能最终拥有多个 OpenID Connect providers您的应用程序可能会使用。但是，尽管它们都共享相同的协议(protocol)技术实现，但需要有一种方法让它们独立工作并单独配置实例。
这是通过给每个“身份验证方案”一个唯一名称来解决的。添加方案时，基本上是注册一个新名称并告诉注册它应该使用哪种处理程序类型。此外，您可以使用 IConfigureNamedOptions<T> 配置每个方案。当你实现它时，基本上会传递一个未配置的选项对象，然后配置 - 如果名称匹配。因此对于每种身份验证类型 T ，最终会有 IConfigureNamedOptions<T>的多次注册可以为方案配置单独的选项对象。
在某些时候，特定方案的身份验证处理程序运行并需要实际配置的选项对象。为此，它取决于 IOptionsFactory<T>谁的 default implementation使您能够创建一个具体的选项对象，然后由所有这些对象进行配置 IConfigureNamedOptions<T>处理程序。
您可以利用选项工厂的确切逻辑来实现一种“命名依赖”。翻译成您的特定示例，例如可能如下所示:

// container type to hold the client and give it a name
public class NamedHttpClient
{
    public string Name { get; private set; }
    public HttpClient Client { get; private set; }

    public NamedHttpClient (string name, HttpClient client)
    {
        Name = name;
        Client = client;
    }
}

// factory to retrieve the named clients
public class HttpClientFactory
{
    private readonly IDictionary<string, HttpClient> _clients;

    public HttpClientFactory(IEnumerable<NamedHttpClient> clients)
    {
        _clients = clients.ToDictionary(n => n.Name, n => n.Client);
    }

    public HttpClient GetClient(string name)
    {
        if (_clients.TryGet(name, out var client))
            return client;

        // handle error
        throw new ArgumentException(nameof(name));
    }
}


// register those named clients
services.AddSingleton<NamedHttpClient>(new NamedHttpClient("A", httpClientA));
services.AddSingleton<NamedHttpClient>(new NamedHttpClient("B", httpClientB));

然后，您将注入(inject) HttpClientFactory某处并使用它的 GetClient检索命名客户端的方法。
显然，如果你考虑一下这个实现和我之前写的内容，那么这看起来非常类似于服务定位器模式。从某种意义上说，在这种情况下它确实是一个，尽管它构建在现有的依赖注入(inject)容器之上。这是否使它变得更好？可能不是，但这是一种使用现有容器实现您的需求的方法，所以这很重要。顺便说一句，为了全面防御，在上面的身份验证选项案例中，选项工厂是一个真正的工厂，因此它构建实际对象并且不使用现有的预注册实例，因此从技术上讲，它不是那里的服务位置模式。

显然，另一种选择是完全忽略我上面写的内容，并在 ASP.NET Core 中使用不同的依赖注入(inject)容器。例如， Autofac支持命名依赖，它可以 easily replace the default container for ASP.NET Core .