返回

.NET Core 原生 DI 扩展之基于名称的注入实现

接触 .NET Core 有一段时间了,最大的感受无外乎无所不在的依赖注入,以及抽象化程度更高的全新框架设计。想起三年前 Peter 大神手写 IoC 容器时的惊艳,此时此刻,也许会有不一样的体会。的确,那个基于字典实现的 IoC 容器相当“简陋”,就像 .NET Core 里的依赖注入,默认(原生)都是采用构造函数注入的方式,可其实从整个依赖注入的理论上而言,属性注入和方法注入的方式,同样是依赖注入的实现方式啊。最近一位朋友找我讨论,.NET Core 里该如何实现 Autowried,这位朋友本身是 Java 出身,一番攀谈了解到原来是指属性注入啊。所以,我打算用两篇博客来聊聊 .NET Core 中的原生 DI 的扩展,而今天这篇,则单讲基于名称的注入的实现。

Autofac是一个非常不错的 IoC 容器,通常我们会使用它来替换微软内置的 IoC 容器。为什么要这样做呢?其实,微软在其官方文档中早已给出了说明,即微软内置的 IoC 容器实际上是不支持以下特性的: 属性注入、基于名称的注入、子容器、自定义生存期管理、对迟缓初始化的 Func 支持、基于约定的注册。这是我们为什么要替换微软内置的 IoC 容器的原因,除了 Autofac 以外,我们还可以考虑 UnityCastle 等容器,对我个人而言,其实最需要的一个功能是“扫描”,即它可以针对程序集中的组件或者服务进行自动注册。这个功能可以让人写起代码更省心一点,果然,人类的本质就是让自己变得更加懒惰呢。好了,话题拉回到本文主题,我们为什么需要基于名称的注入呢?它其实针对的是“同一个接口对应多种不同的实现”这种场景。

OK ,假设我们现在有一个接口 ISayHello,它对外提供一个方法 SayHello:

1public interface ISayHello
2{
3  string SayHello(string receiver);
4}

相对应地,我们有两个实现类,ChineseSayHello 和 EnglishSayHello:

 1//ChineseSayHello
 2public class ChineseSayHello : ISayHello
 3{
 4  public string SayHello(string receiver)
 5  {
 6      return $"你好,{receiver}";
 7  }
 8}
 9
10//EnglishSayHello
11public class EnglishSayHello : ISayHello
12{
13  public string SayHello(string receiver)
14  {
15      return $"Hello,{receiver}";
16  }
17}

接下来,一顿操作猛如虎:

1var services = new ServiceCollection();
2services.AddTransient<ISayHello, ChineseSayHello>();
3services.AddTransient<ISayHello, EnglishSayHello>();
4var serviceProvider = services.BuildServiceProvider();
5var sayHello = serviceProvider.GetRequiredService<ISayHello>();

没想到,尴尬的事情就发生了,大家来猜猜看,这个时候我们获取到的ISayHello到底是哪一个呢?事实上,它会获取到EnglishSayHello这个实现类,为什么呢?因为它后注册的呀!当然,微软的工程师们不可能想不到这个问题,所以,官方推荐的做法是使用IEnumerable<ISayHello>,这样我们就能拿到所有注册的ISayHello,然后自己决定到底要使用一种实现,类似下面这样:

1var sayHellos = _serviceProvider.GetRequiredService<IEnumerable<ISayHello>>();
2var chineseSayHello = sayHellos.FirstOrDefault(x => x.GetType() == (typeof(ChineseSayHello)));
3var englishSayHello = sayHellos.FirstOrDefault(x => x.GetType() == (typeof(EnglishSayHello)));

可这样还是有一点不方便啊,继续改造:

 1services.AddTransient<ChineseSayHello>();
 2services.AddTransient<EnglishSayHello>();
 3services.AddTransient(implementationFactory =>
 4{
 5  Func<string, ISayHello> sayHelloFactory = lang =>
 6  {
 7    switch (lang)
 8    {
 9      case "Chinese":
10        return implementationFactory.GetService<ChineseSayHello>();
11      case "English":
12        return implementationFactory.GetService<EnglishSayHello>();
13      default:
14        throw new NotImplementedException();
15    }
16  };
17
18  return sayHelloFactory;
19});

这样子,这个工厂类看起来就消失了对吧,其实并没有(逃

1var sayHelloFactory = _serviceProvider.GetRequiredService<Func<string, ISayHello>>();
2var chineseSayHello = sayHelloFactory("Chinese");
3var englishSayHello = sayHelloFactory("English");

这距离我们的目标有一点接近了哈,唯一的遗憾是这个工厂类对调用方是透明的,可谓是隐藏细节上的失败。有没有更好的方案呢?好了,我不卖关子啦,一起来看下面的实现。

首先,我们定义一个接口INamedServiceProvider, 顾名思义,就不需要再解释什么了:

1public interface INamedServiceProvider
2{
3  TService GetService<TService>(string serviceName);
4}

接下来,编写实现类NamedServiceProvider:

 1public class NamedServiceProvider : INamedServiceProvider
 2{
 3  private readonly IServiceProvider _serviceProvider;
 4  private readonly IDictionary<string, Type> _registrations;
 5  public NamedServiceProvider(IServiceProvider serviceProvider, IDictionary<string, Type> registrations)
 6  {
 7    _serviceProvider = serviceProvider;
 8    _registrations = registrations;
 9  }
10
11  public TService GetService<TService>(string serviceName)
12  {
13    if(!_registrations.TryGetValue(serviceName, out var implementationType))
14      throw new ArgumentException($"Service \"{serviceName}\" is not registered in container");
15    return (TService)_serviceProvider.GetService(implementationType);
16  }
17}

可以注意到,我们这里用一个字典来维护名称和类型间的关系,一切仿佛又回到三年前 Peter 大神手写 IoC 的那个下午。接下来,我们定义一个INamedServiceProviderBuilder, 它可以让我们使用链式语法注册服务:

1public interface INamedServiceProviderBuilder
2{
3  INamedServiceProviderBuilder AddNamedService<TService>(string serviceName, ServiceLifetime lifetime) where TService : class;
4
5  INamedServiceProviderBuilder TryAddNamedService<TService>(string serviceName, ServiceLifetime lifetime) where TService : class;
6
7  void Build();
8}

这里,Add 和 TryAdd 的区别就是后者会对已有的键进行检查,如果键存在则不会继续注册,和微软自带的 DI 中的 Add/TryAdd 对应,我们一起来看它的实现:

 1public class NamedServiceProviderBuilder : INamedServiceProviderBuilder
 2{
 3  private readonly IServiceCollection _services;
 4  private readonly IDictionary<string, Type> _registrations = new Dictionary<string, Type>();
 5  public NamedServiceProviderBuilder(IServiceCollection services)
 6  {
 7    _services = services;
 8  }
 9
10  public void Build()
11  {
12    _services.AddTransient<INamedServiceProvider>(sp => new NamedServiceProvider(sp, _registrations));
13  }
14
15  public INamedServiceProviderBuilder AddNamedService<TImplementation>(string serviceName, ServiceLifetime lifetime) where TImplementation : class
16  {
17    switch (lifetime)
18    {
19      case ServiceLifetime.Transient:
20        _services.AddTransient<TImplementation>();
21      break;
22      case ServiceLifetime.Scoped:
23        _services.AddScoped<TImplementation>();
24      break;
25      case ServiceLifetime.Singleton:
26        _services.AddSingleton<TImplementation>();
27      break;
28    }
29
30    _registrations.Add(serviceName, typeof(TImplementation));
31    return this;
32  }
33
34  public INamedServiceProviderBuilder TryAddNamedService<TImplementation>(string serviceName, ServiceLifetime lifetime) where TImplementation : class
35  {
36    switch (lifetime)
37    {
38      case ServiceLifetime.Transient:
39        _services.TryAddTransient<TImplementation>();
40      break;
41      case ServiceLifetime.Scoped:
42        _services.TryAddScoped<TImplementation>();
43      break;
44      case ServiceLifetime.Singleton:
45        _services.TryAddSingleton<TImplementation>();
46      break;
47    }
48
49    _registrations.TryAdd(serviceName, typeof(TImplementation));
50    return this;
51  }
52}

相信到这里,大家都明白博主的意图了吧,核心其实是在Build()方法中,因为我们最终需要的是其实是NamedServiceProvider,而在此之前的种种,都属于收集依赖、构建 ServiceProvider 的过程,所以,它被定义为NamedServiceProviderBuilder,我们在这里维护的这个字典,最终会被传入到NamedServiceProvider的构造函数中,这样我们就知道根据名称应该返回哪一个服务了。

接下来,为了让它和微软自带的 DI 无缝粘合,我们需要编写一点扩展方法:

 1public static class ServiceCollectionExstension
 2{
 3  public static TService GetNamedService<TService>(this IServiceProvider serviceProvider, string serviceName)
 4  {
 5    var namedServiceProvider = serviceProvider.GetRequiredService<INamedServiceProvider>();
 6    if (namedServiceProvider == null)
 7      throw new ArgumentException($"Service \"{nameof(INamedServiceProvider)}\" is not registered in container");
 8
 9    return namedServiceProvider.GetService<TService>(serviceName);
10  }
11
12
13  public static INamedServiceProviderBuilder AsNamedServiceProvider(this IServiceCollection services)
14  {
15    var builder = new NamedServiceProviderBuilder(services);
16    return builder;
17  }
18}

现在,回到我们一开始的问题,它是如何被解决的呢?

1services
2  .AsNamedServiceProvider()
3  .AddNamedService<ChineseSayHello>("Chinese", ServiceLifetime.Transient)
4  .AddNamedService<EnglishSayHello>("English", ServiceLifetime.Transient)
5  .Build();
6var serviceProvider = services.BuildServiceProvier();
7var chineseSayHello = serviceProvider.GetNamedService<ISayHello>("Chinese");
8var englishSayHello = serviceProvider.GetNamedService<ISayHello>("English");

这个时候,对调用方而已,依然是熟悉的 ServiceProvider,它只需要传入一个名称来获取服务即可,由此,我们就实现了基于名称的依赖注入。回顾一下它的实现过程,其实是一个逐步推进的过程,我们使用依赖注入,本来是希望依赖抽象,即针对同一个接口,可以无痛地从一种实现切换到另外一种实现。可我们发现,当这些实现同时被注册到容器里的时候,容器一样会迷惑于到底用哪一种实现,这就让我们开始思考,这种基于字典的 IoC 容器设计方案是否存在缺陷。所以,在.NET Core 里的 DI 设计中还引入了工厂的概念,因为并不是所以的 Resolve都可以通过Activator.Create来实现,更不必说 Autofac 和 Castle 中还有子容器的概念,只能说人生不同的阶段总会有不同的理解吧!好了,这篇博客就先写到这里,欢迎大家给我留言,晚安!

Built with Hugo
Theme Stack designed by Jimmy