这个系列已经写了5篇,链接地址如下:

如果想对本篇有个更好的了解,建议需要先看

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

[Asp.net 5] DependencyInjection项目代码分析4-微软的实现(1)

[Asp.net 5] DependencyInjection项目代码分析4-微软的实现(2)”。

在之前的“上“、”中“俩篇已经介绍了ServiceTable、IGenericService、IService、IServiceCallSiteServiceEntryGenericServiceInstanceService、FactoryServiceService等类。本节主要介绍核心的”ServiceProvider“类。

IServiceProvider类

IServiceProvider类是微软这套DependencyInjection中直接对外的接口。而ServiceProvider是直接实现IServiceProvider并且对外直接提供功能的核心类。

对于ServiceProvider不仅要能够获取注入的类,还需要根据不同定义的范围获取不同范围的注入类。对于不同的范围(Transient、Scoped、Singleton),ServiceProvider需要使用不同的逻辑。我们简单分析下。

  • 对于Transient,每次都创建一个新的实例,所以代码中只需直接创建该注入类的实例即可,不需要对该类进行缓存;
  • 对于Singleton,全局只有一个实例,代码中可以将创建的对象缓存到静态的字典表中,之后每次需要该类型实例首先到全局静态字典表中去查找如果存在则直接返回,不存在创建后加入到字典表中,之后返回。(实际上源码中并未缓存到全局变量中,具体实现方式后面会讲解
  • 对于Scoped,每个Scope内是唯一的,不同Scope范围是不同的。这个就比较难实现。不过我们可以通过外部调用的代码简单的猜测下,之后我们通过查看源代码进行验证。

下面是不同Scoped范围的代码调用。

public void ScopedServiceCanBeResolved()
{
IServiceProvider container = CreateContainer();
var scopeFactory = container.GetService<IServiceScopeFactory>();
using (var scope = scopeFactory.CreateScope())
{
var containerScopedService = container.GetService<IFakeScopedService>();
var scopedService1 = scope.ServiceProvider.GetService<IFakeScopedService>();
var scopedService2 = scope.ServiceProvider.GetService<IFakeScopedService>();
Assert.NotEqual(containerScopedService, scopedService1);
Assert.Equal(scopedService1, scopedService2);
}
} [Fact]
public void NestedScopedServiceCanBeResolved()
{
IServiceProvider container = CreateContainer();
IServiceScopeFactory outerScopeFactory = container.GetService<IServiceScopeFactory>();
using (var outerScope = outerScopeFactory.CreateScope())
{
var innerScopeFactory = outerScope.ServiceProvider.GetService<IServiceScopeFactory>();
using (var innerScope = innerScopeFactory.CreateScope())
{
var outerScopedService = outerScope.ServiceProvider.GetService<IFakeScopedService>();
var innerScopedService = innerScope.ServiceProvider.GetService<IFakeScopedService>();
Assert.NotEqual(outerScopedService, innerScopedService);
}
}
}

CreateScope

我们可以根据不同Scoped的注入实例,实际上是通过获取不同的IServiceScope对象ServiceProvider属性,之后通过该属性创建。由于是不同的IServiceScope对象,我们可以大胆的假设IServiceScope对象的ServiceProvider属性也是不同的IServiceProvider对象。所以每个ServiceProvider对象内部,只需要维护一份注入对象的副本即可;由于IServiceScope对象实现了IDisposable接口(用在using上的对象,都实现了IDisposable接口,当using范围结束后,会自动调用IDisposable的Dispose方法),但注入的对象缓存在IServiceScope的ServiceProvider属性对象中,所以我们让ServiceProvider类也实现IDisposable接口,在IServiceScope的Dispose方法内部调用ServiceProvider类的Dispose方法即可。

通过上面的分析,我们可以大致想象出ServiceProvider类的定义,下面就是ServiceProvider类缩减的源代码:

internal class ServiceProvider : IServiceProvider, IDisposable
{
private readonly object _sync = new object(); private readonly ServiceProvider _root;
private readonly ServiceTable _table; private readonly Dictionary<IService, object> _resolvedServices = new Dictionary<IService, object>();
private ConcurrentBag<IDisposable> _disposables = new ConcurrentBag<IDisposable>(); public ServiceProvider(IEnumerable<ServiceDescriptor> serviceDescriptors)
{
_root = this;
_table = new ServiceTable(serviceDescriptors); _table.Add(typeof(IServiceProvider), new ServiceProviderService());
_table.Add(typeof(IServiceScopeFactory), new ServiceScopeService());
_table.Add(typeof(IEnumerable<>), new OpenIEnumerableService(_table));
} internal ServiceProvider(ServiceProvider parent)
{
_root = parent._root;
_table = parent._table;
} public object GetService(Type serviceType);


public void Dispose()
{
var disposables = Interlocked.Exchange(ref _disposables, null); if (disposables != null)
{
foreach (var disposable in disposables)
{
disposable.Dispose();
}
}
}
}

对于ServiceProvider对象共有5个属性,

  • “_sync”是用于多线程同步的锁对象,我们可以不关心。
  • ServiceTable的“_table”对象,是内部维护注入类关系的字典表。
  • resolvedServices是用于维护在该范围内已经创建好的注入对象,当有该范围内的对象,首先会判断该字典表中是否存在实例,如果存在直接返回,不存在创建新的实例加入到该字典表中,并将该新创建的实例返回。
  • “disposables”是一个多线程支持的列表,从名字就看出这是调用Dispose后需要释放的对象。从Dispose方法也可以认证这点。(当注入的对象是实现了IDisposable接口,就需要在使用结束后调用其Dispose方法将其使用的关键资源释放掉,以免造成内存垃圾和资源浪费。)
  • ServiceProvider类型的“root”属性,这个.....(我估计十有八九会问这是什么鬼?难道ServiceProvider也是链形结构?但是那也不能叫root啊?难道是Singleton的实现,但是为毛不是全局的,而且每个ServiceProvider都有这个副本呢??)。经过参考其简单到鬼的注释,和反复试验发现确实是Singleton的实现。

ServiceProvider的Root属性展开

首先我们刚才没有注意到一个问题,就是ServiceProvider类定义不是public的,而是internal的。来我们回忆下类的定义:

internal class ServiceProvider : IServiceProvider, IDisposable

所以我们在外面是无法调用/构建ServiceProvider的实例的,只能在程序集范围内实例话。那在哪些地方调用该类的构造函数呢?
结果发现俩个构造函数都只被调用过一次。下面将调用的代码列出:

public static class ServiceCollectionExtensions
{
public static IServiceProvider BuildServiceProvider(this IServiceCollection services)
{
return new ServiceProvider(services);
}
} internal class ServiceScopeFactory : IServiceScopeFactory
{
private readonly ServiceProvider _provider; public ServiceScopeFactory(ServiceProvider provider)
{
_provider = provider;
} public IServiceScope CreateScope()
{
return new ServiceScope(new ServiceProvider(_provider));
}
}

ServiceProvider构造函数

  • 对于ServiceCollectionExtensions类调用的构造函数:这是对于IServiceCollection接口(继承自 IList<ServiceDescriptor>)的扩展,实际就是用IServiceCollection对象创建出ServiceProvider对象供外面调用。这是微软实现的依赖注入的入口。我们看使用IServiceCollection为参数的ServiceProvider构造函数,[_root=this]。说明新创建的ServiceProvider就是所谓的root。
  • 对于使用ServiceProvider为参数的ServiceProvider构造函数。[root=parent._root],说明通过该构造函数构造出的ServiceProvider对象和传入的ServiceProvider对象的_root实际指向同一块地址,并且都是使用 IServiceCollection创建的ServiceProvider对象[需要注意的是正常IServiceCollection.BuildServiceProvider只使用一次,虽然没有定义成全局唯一]。也就是说,使用IServiceCollection.BuildServiceProvider创建的ServiceProvider的作用域是全局的,使用ServiceProvider直接创建的scpoed范围的对象,也会成为全局的对象(没有时机调用其IDisposable接口)。
public ServiceProvider(IEnumerable<ServiceDescriptor> serviceDescriptors)
{
_root = this;
_table = new ServiceTable(serviceDescriptors); _table.Add(typeof(IServiceProvider), new ServiceProviderService());
_table.Add(typeof(IServiceScopeFactory), new ServiceScopeService());
_table.Add(typeof(IEnumerable<>), new OpenIEnumerableService(_table));
} internal ServiceProvider(ServiceProvider parent)
{
_root = parent._root;
_table = parent._table;
}

ServiceProvider的属性我们已经讲完,那我们继续看下构造函数内其他的东西(上面的代码就是其构造函数)。我们发现ServiceTable内额外添加IServiceProvider、IServiceScopeFactory、IEnumerable<>的注入。

  • IServiceProvider的注入,说明能够创建新的IServiceProvider。我们上面说了只有俩个地方能够创建新的ServiceProvider,并且并不包含ServiceProviderService方法啊。实际上ServiceProviderService是之前介绍的IService, IServiceCallSite接口的实现类,当调用IServiceCallSite的方法” Invoke(ServiceProvider provider)“时,直接返回provider,并没有创建新的ServiceProvider(IServiceProvider)对象,而是使用现有的
  • IServiceScopeFactory注入,ServiceScopeService也是实现了IService, IServiceCallSite接口,并且内部会创建ServiceScopeFactory(IServiceScopeFactory)。
  • IEnumerable<>的注入,由于篇幅有限,将额外介绍,该处就略过了。
internal class ServiceProviderService : IService, IServiceCallSite
{
public IService Next { get; set; } public ServiceLifetime Lifetime
{
get { return ServiceLifetime.Scoped; }
} public IServiceCallSite CreateCallSite(ServiceProvider provider, ISet<Type> callSiteChain)
{
return this;
} public object Invoke(ServiceProvider provider)
{
return provider;
} public Expression Build(Expression provider)
{
return provider;
}
}

ServiceProviderService

internal class ServiceScopeService : IService, IServiceCallSite
{
public IService Next { get; set; } public ServiceLifetime Lifetime
{
get { return ServiceLifetime.Scoped; }
} public IServiceCallSite CreateCallSite(ServiceProvider provider, ISet<Type> callSiteChain)
{
return this;
} public object Invoke(ServiceProvider provider)
{
return new ServiceScopeFactory(provider);
} public Expression Build(Expression provider)
{
return Expression.New(
typeof(ServiceScopeFactory).GetTypeInfo()
.DeclaredConstructors
.Single(),
provider);
}
} internal class ServiceScopeFactory : IServiceScopeFactory
{
private readonly ServiceProvider _provider; public ServiceScopeFactory(ServiceProvider provider)
{
_provider = provider;
} public IServiceScope CreateScope()
{
return new ServiceScope(new ServiceProvider(_provider));
}
} internal class ServiceScope : IServiceScope
{
private readonly ServiceProvider _scopedProvider; public ServiceScope(ServiceProvider scopedProvider)
{
_scopedProvider = scopedProvider;
} public IServiceProvider ServiceProvider
{
get { return _scopedProvider; }
} public void Dispose()
{
_scopedProvider.Dispose();
}
}

ServiceScopeService、ServiceScopeFactory、ServiceScope

[Asp.net 5] DependencyInjection项目代码分析4-微软的实现(3)的更多相关文章

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

    微软DI文章系列如下所示: [Asp.net 5] DependencyInjection项目代码分析 [Asp.net 5] DependencyInjection项目代码分析2-Autofac [ ...

  2. [Asp.net 5] DependencyInjection项目代码分析4-微软的实现(5)(IEnumerable<>补充)

    Asp.net 5的依赖注入注入系列可以参考链接: [Asp.net 5] DependencyInjection项目代码分析-目录 我们在之前讲微软的实现时,对于OpenIEnumerableSer ...

  3. [Asp.net 5] DependencyInjection项目代码分析4-微软的实现(4)

    这个系列已经写了6篇,链接地址如下: [Asp.net 5] DependencyInjection项目代码分析 [Asp.net 5] DependencyInjection项目代码分析2-Auto ...

  4. [Asp.net 5] DependencyInjection项目代码分析4-微软的实现(2)

    在 DependencyInjection项目代码分析4-微软的实现(1)中介绍了“ServiceTable”.“ServiceEntry”.“IGenericService”.“IService”. ...

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

    最近在研究开源代码,正好发现Asp.net5的源码,下载地址:https://github.com/aspnet. 今天主要讲的是DependencyInjection这部分,抛砖引玉,供大家参考,也 ...

  6. [Asp.net 5] DependencyInjection项目代码分析2-Autofac

    Microsoft.Framework.DependencyInjection.Autofac源码分析 该工程只有一个代码静态类AutofacRegistration,但是该类有3个扩展方法,以及3个 ...

  7. [Asp.net 5] DependencyInjection项目代码分析3-Ninject

    Microsoft.Framework.DependencyInjection.Ninject 该工程内部共包含5个类文件,底层使用Ninject实现依赖注入,工程截图如下: 从文件命名可以看出,Ni ...

  8. [Asp.net 5] DependencyInjection项目代码分析4-微软的实现(1)

    前面俩种实现中,很多内部细节都无法知道,微软的框架也是为了屏蔽具体实现,只让我们关注接口.但是人都是充满好奇的,依赖注入到底是怎么实现的呢? 微软又有怎样的实现呢?下面就为大家一一呈现(说实话,代码真 ...

  9. Jenkins+Gradle+Sonar进行Java项目代码分析

    Jenkins+Maven+Sonar与Jenkins+Gradle+Sonar配置方法很相似,区别就是Java项目所用的编译工具不同,一个是maven,一个是gradle 使用maven编译工具的可 ...

随机推荐

  1. PSP

    PSP2.1 Time(%) Planning 10 l Estimate 10 Development 90 l Analysis 10 l Design Spec 5 l Design Revie ...

  2. 【读书笔记】.Net并行编程(三)---并行集合

    为了让共享的数组,集合能够被多线程更新,我们现在(.net4.0之后)可以使用并发集合来实现这个功能.而System.Collections和System.Collections.Generic命名空 ...

  3. 正式工作的前奏——一个Java程序员的实习总结(1)

    不知不觉,到深圳实习已经三个礼拜了.跟在暑假的三个半月实习不一样,这次收获更多,感受更好,算是摆脱了那次实习给我带来的阴影(这个会放到以后才说). 在知乎上,有这么一个问题,你现在最想跟刚工作时的你说 ...

  4. [stm32] STM32 Interrupts and events 系统了解(EXTI)及槽型光电开关tp850电路研究

    中断和事件 1 嵌套向量中断控制器 特性: ● 68个可屏蔽中断通道(不包含16个Cortex™-M3的中断线):● 16个可编程的优先等级(使用了4位中断优先级):● 低延迟的异常和中断处理:● 电 ...

  5. [ACM_贪心] Radar Installation

    http://acm.hust.edu.cn/vjudge/contest/view.action?cid=28415#problem/A 题目大意:X轴为海岸线可放雷达监测目标点,告诉n个目标点和雷 ...

  6. Senparc.Weixin.MP SDK 微信公众平台开发教程(十六):AccessToken自动管理机制

    在<Senparc.Weixin.MP SDK 微信公众平台开发教程(八):通用接口说明>中,我介绍了获取AccessToken(通用接口)的方法. 在实际的开发过程中,所有的高级接口都需 ...

  7. MVVM架构~Knockoutjs系列之对象与对象组合

    返回目录 在面向对象的程序设计里,对象是核心,一切皆为对象,对象与对象之间的关系可以表现为继承和组合,而在Knockoutjs或者JS里,也存在着对象的概念,今天主要说一下JS里的对象及对象的组合. ...

  8. JSONP浅析

    DEMO : JSONP示例 为什么使用JSONP JSONP和JSON是不一样的.JSON(JavaScript Object Notation)是一种基于文本的数据交换方式,或者叫做数据描述格式. ...

  9. paip.禁用IKAnalyzer 的默认词库.仅仅使用自定义词库.

    paip.禁用IKAnalyzer 的默认词库.仅仅使用自定义词库. 作者Attilax  艾龙,  EMAIL:1466519819@qq.com  来源:attilax的专栏 地址:http:// ...

  10. java异常处理:建立exception包,建立Bank类,类中有变量double balance表示存款,Bank类的构造方法能增加存款,Bank类中有取款的发方法withDrawal(double dAmount),当取款的数额大于存款时,抛出InsufficientFundsException,取款数额为负数,抛出NagativeFundsException,如new Bank(100),

    建立exception包,建立Bank类,类中有变量double  balance表示存款,Bank类的构造方法能增加存款,Bank类中有取款的发方法withDrawal(double dAmount ...