ServiceDescriptor在.net core中的作用就是DI中注入服务元素的描述.每一个元素核心内容部分包括需要注入的服务元素的类型ServiceType,它对应的接口(如果有的话)ImplementationType,以及服务元素的生命周期ServiceLifetime. 源码中ServiceDescriptor是一个普通类,一共有4个构造函数,分别是如下: public ServiceDescriptor(Type serviceType, Type implementationT

这篇随笔主要记录一下ASP.NET Core团队实现默认的依赖注入容器的过程,我的理解可能并不是正确的. DependencyInjection这个项目不大,但却是整个ASP.NET Core的基础,因为它提供了依赖注入(DI)容器的默认实现,而依赖注入贯穿整个ASP.NET Core.相关源码可以去GitHub AspNet 上下载. 要实现是一个依赖注入容器,主要是实现它添加依赖.描述依赖.存储依赖和解析依赖的能力,可以分别用Add(A), Describe(D), Store(S), Re

在上一篇文章中我们主要分析了ASP.NET Core默认依赖注入容器的存储和解析,这一篇文章主要补充一下上一篇文章忽略的一些细节:有关服务回收的问题,即服务的生命周期问题.有关源码可以去GitHub上找到. 这次的主角就是ServiceProvider一人,所有有关生命周期的源码几乎都集中在ServiceProvider.cs这个文件中. 我们知道服务的生命周期由三种,分别是: Transient Scoped Singleton 首先给出我的结论:这三种生命周期类别本质上没有区别,服务的生命周

在上一篇中,介绍了一下Options的注册,而使用时只需要注入IOption即可: public ValuesController(IOptions<MyOptions> options) { var opt = options.Value; } IOptions IOptions 定义非常简单,只有一个Value属性: public interface IOptions<out TOptions> where TOptions : class, new() { TOptions

配置的本质就是字符串的键值对,但是对于面向对象语言来说,能使用强类型的配置是何等的爽哉! 目录 ASP.NET Core 配置系统 强类型的 Options Configure 方法 源码解析 ASP.NET Core 配置系统 在ASP.NET 4.X中,通常将配置存储在 web.config 中,使用静态帮助类来获取这些配置,而对 web.cofng 中进行任何修改时,则会导致应用程序池的回收,这种实现方式并不是很友好. 因此,在ASP.NET Core中,对配置系统进行了重写,仍然使用的是

在 上一章 中,介绍了 IOptions 的使用, 而我们知道,在ConfigurationBuilder的AddJsonFile中,有一个reloadOnChange参数,设置为true时,在配置文件发生变化时,会自动更新IConfigurationRoot,这是一个非常棒的特性,遗憾的是 IOptions 在配置源发生变化时,并不会进行更新.好在,微软还为我们提供了 IOptionsSnapshot ,本篇就来探索一下其源码. IOptionsSnapshot IOptionsSnapsho

前面我们讲到 IOptions 和 IOptionsSnapshot,他们两个最大的区别便是前者注册的是单例模式,后者注册的是 Scope 模式.而 IOptionsMonitor 则要求配置源必须是可监听的,用来实现 Options 实例的自动更新,并对外提供了 OnChage 事件,给我们更多的控制权. IOptionsMonitor public interface IOptionsMonitor<out TOptions> { TOptions CurrentValue { get;

在上一章中,我们对 ASP.NET Logging 系统做了一个整体的介绍,而在本章中则开始从最基本的配置开始,逐步深入到源码当中去. 默认配置 在 ASP.NET Core 2.0 中,对默认配置做了很大的简化,并把一些基本配置移动到了程序的入口点 Program 类中,更加简洁. public class Program { public static void Main(string[] args) { BuildWebHost(args).Run(); } public static I

一.简要说明 ABP vNext 框架在使用依赖注入服务的时候,是直接使用的微软提供的 Microsoft.Extensions.DependencyInjection 包.这里与原来的 ABP 框架就不一样了,原来的 ABP 框架还需要抽象出来一个 IIocManager 用来管理整个 IoC 容器,现在则直接操作 IServiceCollection 与 IServiceProvider 进行组件的注册/解析. 这里需要注意的是,虽然现在的依赖注入服务是使用微软官方那一套库进行操作,但是 A

Abp 不一定仅用于 Asp.Net Core 项目,他也可以在 Console 与 WinFrom 项目当中进行使用,所以关于启动流程可以分为两种,一种是 Asp.Net Core 项目的启动流程,另外则是 ConsoleApplication/WinFrom 项目的启动流程,在这里我则是通过 Asp.Net Core 项目的启动流程来分析,但是他们的核心都是 AbpBootstrapper 这个类. 本文章基于 Abp 框架的最新版本 v3.7.2 . 一.Abp 的入口点 1.1 添加服务

0. 简介 整个 Abp 框架最为核心的除了 Abp 库之外,其次就是 Abp.AspNetCore 库了.虽然 Abp 本身是可以用于控制台程序的,不过那样的话 Abp 就基本没什么用,还是需要集合 ASP.NET Core 才能发挥它真正的作用. 在 Abp.AspNetCore 库里面,Abp 通过 WindsorRegistrationHelper.CreateServiceProvider() 接管了 ASP.NET Core 自带的 Ioc 容器.除此之外,还针对 Controlle

配置的本质就是字符串的键值对,但是对于面向对象语言来说,能使用强类型的配置是何等的爽哉! 目录 ASP.NET Core 配置系统 强类型的 Options Configure 方法 ConfigureNamedOptions ASP.NET Core 配置系统 在ASP.NET 4.X中,通常将配置存储在 web.config 中,使用静态帮助类来获取这些配置,而对 web.cofng 中进行任何修改时,则会导致应用程序池的回收,这种实现方式并不是很友好. 因此,在ASP.NET Core中,

上一篇文章已经介绍了MemoryCache,MemoryCache存储的数据类型是Object,也说了Redis支持五中数据类型的存储,但是微软的Redis缓存组件只实现了Hash类型的存储.在分析源码之前,先学几个关于Redis操作的命令. 一.Redis命令 Redis所有的命令在http://doc.redisfans.com/上有详细介绍.下面介绍几个常用的关于Hash类型的命令. HSET:用于添加缓存 用法:HSET key field value . 返回值:如果 field 是哈

一.介绍 由于CPU从内存中读取数据的速度比从磁盘读取快几个数量级,并且存在内存中,减小了数据库访问的压力,所以缓存几乎每个项目都会用到.一般常用的有MemoryCache.Redis.MemoryCache将存入的对象都作为Object对象存储,Redis分为五种类型存储,在微软提供的缓存组件中也包含Redis和SQL Server缓存,具体下次文章详细讲解.微软缓存组件源码在https://github.com/aspnet/Caching. 二.简单使用 组件的使用很简单,只需要添加组件,

在 上一章 中,介绍了Options的注册,而在使用时只需要注入 IOption<T> 即可: public ValuesController(IOptions<MyOptions> options) { var opt = options.Value; } 本章就来详细介绍一下我们最熟悉的IOptions对象. 目录 IOptions OptionsManager OptionsFactory OptionsCache IOptionsSnapshot IOptions IOpt

前面我们讲到 IOptions 和 IOptionsSnapshot,他们两个最大的区别便是前者注册的是单例模式,后者注册的是 Scope 模式.而 IOptionsMonitor 则要求配置源必须是可监听的,用来实现 Options 实例的自动更新,并对外提供了 OnChage 事件,给我们更多的控制权. 目录 IOptionsMonitor OptionsMonitor源码探索 ConfigurationChangeTokenSource 示例 IOptionsMonitor 对于 IOpt

原文链接:https://www.cnblogs.com/RainingNight/p/strongly-typed-options-ioptions-monitor-in-asp-net-core.html 前面我们讲到 IOptions 和 IOptionsSnapshot,他们两个最大的区别便是前者注册的是单例模式,后者注册的是 Scope 模式.而 IOptionsMonitor 则要求配置源必须是可监听的,用来实现 Options 实例的自动更新,并对外提供了 OnChage 事件,给

原文链接:https://www.cnblogs.com/RainingNight/p/strongly-typed-options-ioptions-in-asp-net-core.html 在 上一章 中,介绍了Options的注册,而在使用时只需要注入 IOption<T> 即可: public ValuesController(IOptions<MyOptions> options) { var opt = options.Value; } 本章就来详细介绍一下我们最熟悉的

原文链接:https://www.cnblogs.com/RainingNight/p/strongly-typed-options-configure-in-asp-net-core.html 配置的本质就是字符串的键值对,但是对于面向对象语言来说,能使用强类型的配置是何等的爽哉! 目录 ASP.NET Core 配置系统 强类型的 Options Configure 方法 ConfigureNamedOptions ASP.NET Core 配置系统 在ASP.NET 4.X中,通常将配置存

Asp.NetCore源码学习[1-2]:配置[Option] 在上一篇文章中,我们知道了可以通过IConfiguration访问到注入的ConfigurationRoot,但是这样只能通过索引器IConfiguration["配置名"]访问配置.这篇文章将一下如何将IConfiguration映射到强类型. 本系列源码地址 一.使用强类型访问Configuration的用法 指定需要配置的强类型MyOptions和对应的IConfiguration public void Confi