.NET Core原生DI擴展之基於名稱的注入實現

接觸 .NET Core 有一段時間了，最大的感受無外乎無所不在的依賴注入，以及抽象化程度更高的全新框架設計。想起三年前 Peter 同學手寫 IoC 容器時的驚豔，此時此刻，也許會有不一樣的體會。的確，那個基於字典實現的 IoC 容器相當“簡陋”，就像 .NET Core 裏的依賴注入，默認(原生)都是採用構造函數注入的方式，可其實從整個依賴注入的理論上而言，屬性注入和方法注入的方式，同樣是依賴注入的實現方式啊。最近一位朋友找我討論，.NET Core 裏該如何實現 Autowried，這位朋友本身是 Java 出身，一番攀談了解到原來是指屬性注入啊。所以，我打算用兩篇博客來聊聊 .NET Core 中的原生 DI 的擴展，而今天這篇，則單講基於名稱的注入的實現。

Autofac是一個非常不錯的 IoC 容器，通常我們會使用它來替換微軟內置的 IoC 容器。爲什麼要這樣做呢？其實，微軟在其官方文檔中早已給出了說明，即微軟內置的 IoC 容器實際上是不支持以下特性的： 屬性注入、基於名稱的注入、子容器、自定義生存期管理、對遲緩初始化的 Func 支持、基於約定的註冊。這是我們爲什麼要替換微軟內置的 IoC 容器的原因，除了Autofac 以外，我們還可以考慮 Unity 、Castle 等容器，對我個人而言，其實最需要的一個功能是“掃描”，即它可以針對程序集中的組件或者服務進行自動註冊。這個功能可以讓人寫起代碼更省心一點，果然，人類的本質就是讓自己變得更加懶惰呢。好了，話題拉回到本文主題，我們爲什麼需要基於名稱的注入呢？它其實針對的是“同一個接口對應多種不同的實現”這種場景。

OK ，假設我們現在有一個接口ISayHello，它對外提供一個方法SayHello：

public interface ISayHello
{
  string SayHello(string receiver);
}

相對應地，我們有兩個實現類，ChineseSayHello和EnglishSayHello：

//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}";
  }
}

接下來，一頓操作猛如虎：

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，然後自己決定到底要使用一種實現，類似下面這樣：

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

可這樣還是有一點不方便啊，繼續改造：

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;
});

這樣子，這個工廠類看起來就消失了對吧，其實並沒有(逃

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

這距離我們的目標有一點接近了哈，唯一的遺憾是這個工廠類對調用方是透明的，可謂是隱藏細節上的失敗。有沒有更好的方案呢？好了，我不賣關子啦，一起來看下面的實現。

首先，我們定義一個接口INamedServiceProvider, 顧名思義，就不需要再解釋什麼了:

public interface INamedServiceProvider
{
  TService GetService<TService>(string serviceName);
}

接下來，編寫實現類NamedServiceProvider:

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, 它可以讓我們使用鏈式語法註冊服務：

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對應，我們一起來看它的實現：

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無縫粘合，我們需要編寫一點擴展方法：

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;
  }
}

現在，回到我們一開始的問題，它是如何被解決的呢？

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中還有子容器的概念，只能說人生不同的階段總會有不同的理解吧！好了，這篇博客就先寫到這裏，歡迎大家給我留言，晚安！