接触 .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:

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

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

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

//EnglishSayHello
public class EnglishSayHello : ISayHello
{
public string SayHello(string receiver)
{
return $"Hello,{receiver}";
}
}

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

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

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

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

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

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

return sayHelloFactory;
});

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

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

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

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

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

接下来,编写实现类NamedServiceProvider:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
public class NamedServiceProvider : INamedServiceProvider
{
private readonly IServiceProvider _serviceProvider;
private readonly IDictionary<string, Type> _registrations;
public NamedServiceProvider(IServiceProvider serviceProvider, IDictionary<string, Type> registrations)
{
_serviceProvider = serviceProvider;
_registrations = registrations;
}

public TService GetService<TService>(string serviceName)
{
if(!_registrations.TryGetValue(serviceName, out var implementationType))
throw new ArgumentException($"Service \"{serviceName}\" is not registered in container");
return (TService)_serviceProvider.GetService(implementationType);
}
}

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

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

INamedServiceProviderBuilder TryAddNamedService<TService>(string serviceName, ServiceLifetime lifetime) where TService : class;

void Build();
}

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
public class NamedServiceProviderBuilder : INamedServiceProviderBuilder
{
private readonly IServiceCollection _services;
private readonly IDictionary<string, Type> _registrations = new Dictionary<string, Type>();
public NamedServiceProviderBuilder(IServiceCollection services)
{
_services = services;
}

public void Build()
{
_services.AddTransient<INamedServiceProvider>(sp => new NamedServiceProvider(sp, _registrations));
}

public INamedServiceProviderBuilder AddNamedService<TImplementation>(string serviceName, ServiceLifetime lifetime) where TImplementation : class
{
switch (lifetime)
{
case ServiceLifetime.Transient:
_services.AddTransient<TImplementation>();
break;
case ServiceLifetime.Scoped:
_services.AddScoped<TImplementation>();
break;
case ServiceLifetime.Singleton:
_services.AddSingleton<TImplementation>();
break;
}

_registrations.Add(serviceName, typeof(TImplementation));
return this;
}

public INamedServiceProviderBuilder TryAddNamedService<TImplementation>(string serviceName, ServiceLifetime lifetime) where TImplementation : class
{
switch (lifetime)
{
case ServiceLifetime.Transient:
_services.TryAddTransient<TImplementation>();
break;
case ServiceLifetime.Scoped:
_services.TryAddScoped<TImplementation>();
break;
case ServiceLifetime.Singleton:
_services.TryAddSingleton<TImplementation>();
break;
}

_registrations.TryAdd(serviceName, typeof(TImplementation));
return this;
}
}

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

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

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

return namedServiceProvider.GetService<TService>(serviceName);
}


public static INamedServiceProviderBuilder AsNamedServiceProvider(this IServiceCollection services)
{
var builder = new NamedServiceProviderBuilder(services);
return builder;
}
}

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

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

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