[Asp.net 5] DependencyInjection项目代码分析

最近在研究开源代码，正好发现Asp.net5的源码，下载地址：https://github.com/aspnet。

今天主要讲的是DependencyInjection这部分，抛砖引玉，供大家参考，也欢迎莅临斧正。闲话不多说，下面就代码进行简单分析

项目架构如下：

一共包含DependencyInjection、DependencyInjection.Abstractions、DependencyInjection.Autofac、DependencyInjection.Ninject以及DependencyInjection.Tests五个工程。

• DependencyInjection.Abstractions 基础的接口和类，使用时对外暴露的基本信息。
• DependencyInjection 微软自己实现的DI接口
• DependencyInjection.Autofac 使用Autofac（该组件不知道是否是开源的）实现的DI
• DependencyInjection.Ninject 使用Ninject（该组件也不知道是否开源）实现的DI
• DependencyInjection.Tests 对于上面四个工程的测试代码，该部分可以不看，但是对于DI的使用还是有参考价值的。

DependencyInjection.Abstractions

该工程包含基本的接口以及一些基础的类/枚举。对于面向接口编程，使用者不需要知道实现的细节，只需要了解相应的接口便可。另外三个工程（DependencyInjection、DependencyInjection.Autofac、DependencyInjection.Ninject）就是对于该工程的相关接口的实现；使用中可以选择其中一个实现即可，也就是说使用微软这个DI，DependencyInjection.Abstractions是必须引用的类库，另外三个工程（如上所指），引入一个即可。

DependencyInjection.Abstractions 这个工程中包含的文件不是很多，下面我就将该工程文件截图：

该工程中缺少一个关键接口——IServiceProvider，该接口位于System下，有如下定义：

    public interface IServiceProvider
    {
        object GetService(Type serviceType);
    }

该接口的作用是根据传入的类型，并把它转化为相应的实例，该接口是DI的核心，是最终干活的类/接口。
但是该接口的定义存在缺陷，返回值类型是object类型的，用户使用的时候还需要进行强制类型转换，所以就对该接口进行了扩展（ServiceProviderExtensions），扩展的定义如下（省略了具体实现）：

public static class ServiceProviderExtensions
{
        public static T GetService<T>([NotNull] this IServiceProvider provider);

         public static object GetRequiredService([NotNull] this IServiceProvider provider, [NotNull] Type serviceType);

         public static T GetRequiredService<T>([NotNull] this IServiceProvider provider);

         public static IEnumerable<T> GetRequiredServices<T>([NotNull] this IServiceProvider provider);

         public static IEnumerable<object> GetRequiredServices([NotNull] this IServiceProvider provider, [NotNull] Type serviceType);
}

使用ServiceProvidoer创建出来的实例实际是有相应的生命周期的，框架中使用枚举ServiceLifetime表示，定义如下：

public enum ServiceLifetime
    {
        Singleton,//全局唯一
        Scoped,//一定范围的
        Transient//瞬间
    }

一共分为三种，三种的时间长短是Transient<Scoped<Singleton。Transient代表仅当前实例(每次都创建一个新的)，Scoped代表当前范围（会在ServiceScope中定义），Singleton代表全家唯一（类似于单例）。

IServiceScopeFactory和IServiceScope，这俩个接口很简单，故名思义IServiceScopeFactory是Scope的一个工厂类，产生一个ServiceScope对象。IServiceScope对象会生成一个IServiceProvidoer对象，一般来说通过IServiceScope就是枚举Scoped所代表的范围。这俩个接口定义如下：

    public interface IServiceScopeFactory
    {
        IServiceScope CreateScope();
    }

    public interface IServiceScope : IDisposable
    {
        IServiceProvider ServiceProvider { get; }
    }

对于注册成Scoped范围的接口/类，可以通过不同的Scope拿到不同的IServiceProvidoer，之后创建不同的范围的实例，下面我将Tests工程下的一段测试代码拿出来，略作修改（将var 替换成实际的接口，阅读方便）

//services.AddScoped<IFakeScopedService, FakeService>();
public void NestedScopedServiceCanBeResolved()
        {
            IServiceProvider container = CreateContainer();

            IServiceScopeFactory outerScopeFactory = container.GetService<IServiceScopeFactory>();
            using (IServiceScope outerScope = outerScopeFactory.CreateScope())
            {
                IServiceScopeFactory innerScopeFactory = outerScope.ServiceProvider.GetService<IServiceScopeFactory>();
                using (IServiceScope innerScope = innerScopeFactory.CreateScope())
                {
                    IFakeScopedService outerScopedService = outerScope.ServiceProvider.GetService<IFakeScopedService>();
                    IFakeScopedService innerScopedService = innerScope.ServiceProvider.GetService<IFakeScopedService>();

                    Assert.NotEqual(outerScopedService, innerScopedService);
                }
            }
        }

上面几个类的关系大概如下图所示：

 ServiceDescriptor类：该类是一个描述类，描述DI的映射关系。该类的属性主要有3个（并不恰当），注入的源类，注入的生成类，注入的范围（ServiceLifetime）。而对于注入的生成类又分为三种：生成类的类型、生成类的实例、生成类的工厂。所以ServiceDescriptor的定义如下所示：

 public class ServiceDescriptor
    {
        public ServiceLifetime Lifetime { get; }
        public Type ServiceType { get; }
        public Type ImplementationType { get; }
        public object ImplementationInstance { get; }
        public Func<IServiceProvider, object> ImplementationFactory { get; }
    }

IServiceCollection接口比较简单就是 IList<ServiceDescriptor>。ServiceCollectionExtensions是对IServiceCollection接口的扩展方法集合。

这几个类的关系如下图所示：

剩余俩个类：ActivatorUtilities、ObjectFactory（其实是个代理/delegate）是用于反射创建实例。

整个工程我对接口、类、代理、枚举重新划分了下文件夹如下图所示：

将在下一篇文章中对DependencyInjection.Autofac、DependencyInjection.Ninject进行分析，最后再对微软自己的DI实现进行分析。