摘要： 2019年1月19日，微软技术（苏州）俱乐部成立，我受邀在成立大会上作了一个名为《ASP.NET Core框架揭秘》的分享。在此次分享中，我按照ASP.NET Core自身的运行原理和设计思想创建了一个 “迷你版” 的ASP.NET Core框架，并且利用这个 “极简” 的模拟框架阐述了ASP.NET Core框架最核心、最本质的东西。整个框架涉及到的核心代码不会超过200行，涉及到7个核心的对象。由于ASP.NET Core 3.X采用了不同的应用承载方式，所以我们将这个模拟框架升级到3.x版本。 阅读全文

摘要： 我们在《总体设计[上篇]》和《总体设计[下篇]》中通过对IHostedService、IHost和IHostBuider这三个接口的介绍让读者朋友们对服务承载模型有了大致的了解。接下来我们从抽象转向具体，看看承载系统针对该模型的实现是如何落地的。 阅读全文

摘要： 《ASP.NET Core 3框架揭秘》（上下册）在本月正式上市，为此出版社专门创建了一个微信群，。由于目前人数已经超过200人，只能通过邀请方能加入。有兴趣的朋友可以搜索微信账号“broadview002”（博文小丸子）并添加为好友，并在申请消息中指定本书书号“38462”，出版社工作人员将自动帮你添加到该微信群。 阅读全文

摘要： 前面的实例演示了服务承载的基本编程模式，接下来我们从设计的角度来重新认识服务承载模型。总的来说，服务承载模型主要由三个核心对象组成：多个通过IHostedService接口表示的服务被承载于通过IHost接口表示的宿主上，IHostBuilder接口表示IHost对象的构建者。 阅读全文

摘要： 前面的实例演示了服务承载的基本编程模式，接下来我们从设计的角度来重新认识服务承载模型。总的来说，服务承载模型主要由如下图所示的三个核心对象组成：多个通过IHostedService接口表示的服务被承载于通过IHost接口表示的宿主上，IHostBuilder接口表示IHost对象的构建者。 阅读全文

摘要： 借助.NET Core提供的承载（Hosting）系统，我们可以将任意一个或者多个长时间运行（Long-Running）的服务寄宿或者承载于托管进程中。ASP.NET Core应用仅仅是该承载系统的一种典型的服务类型而已，任何需要在后台长时间运行的操作都可以定义成标准化的服务并利用该系统来承载。 阅读全文

摘要： 借助.NET Core提供的承载（Hosting）系统，我们可以将任意一个或者多个长时间运行（Long-Running）的服务寄宿或者承载于托管进程中。ASP.NET Core应用仅仅是该承载系统的一种典型的服务类型而已，任何需要在后台长时间运行的操作都可以定义成标准化的服务并利用该系统来承载。 阅读全文

摘要： Options模型本身与配置系统完全没有关系，但是配置在大部分情况下会作为绑定Options对象的数据源，所以有必要将两者结合在一起。与《扩展与定制》演示的两个例子一样，针对配置系统的集成同样是通过定制Options模型相应的对象来实现的 阅读全文

摘要： 由于Options模型涉及的核心对象最终都注册为相应的服务，所以从原则上讲这些对象都是可以定制的，下面提供几个这样的实例。由于Options模型提供了针对配置系统的集成，所以可以采用配置文件的形式来提供原始的Options数据，可以直接采用反序列化的方式将配置文件的内容转换成Options对象。 阅读全文

摘要： 《Options模型》介绍了组成Options模型的4个核心对象以及它们之间的交互关系，读者对如何得到Options对象的实现原理可能不太了解，本篇文章主要介绍依赖注入的相关内容。既然我们能够利用IServiceProvider对象提供的IOptions 阅读全文

摘要： IOptionsFactory解决了Options的创建与初始化问题，但由于它自身是无状态的，所以Options模型对Options对象实施缓存可以获得更好的性能。Options模型中针对Options对象的缓存由IOptionsMonitorCache对象来完成。Options模型之所以将表示缓存的接口命名为IOptionsMonitorCache，是因为缓存最初是为IOptionsMonitor对象服务的，该对象旨在实现针对承载Options对象的原始数据源的监控，并在检测到数据更新后及时替换缓存的Options对象。 阅读全文

摘要： 通过前面演示的几个实例（配置选项的正确使用方式[上篇]、配置选项的正确使用方式[下篇]），我们已经对基于Options的编程方式有了一定程度的了解，下面从设计的角度介绍Options模型。我们演示的实例已经涉及Options模型的3个重要的接口，它们分别是IOptions 阅读全文

摘要： 依赖注入不仅是支撑整个ASP.NET Core框架的基石，也是开发ASP.NET Core应用采用的基本编程模式，所以依赖注入十分重要。依赖注入使我们可以将依赖的功能定义成服务，最终以一种松耦合的形式注入消费该功能的组件或者服务中。除了采用依赖注入的形式消费承载某种功能的服务，还可以采用相同的方式消费承载配置数据的Options对象。 阅读全文

摘要： 依赖注入不仅是支撑整个ASP.NET Core框架的基石，也是开发ASP.NET Core应用采用的基本编程模式，所以依赖注入十分重要。依赖注入使我们可以将依赖的功能定义成服务，最终以一种松耦合的形式注入消费该功能的组件或者服务中。除了采用依赖注入的形式消费承载某种功能的服务，还可以采用相同的方式消费承载配置数据的Options对象。 阅读全文

摘要： 我们在前面对配置模型中默认提供的各种IConfigurationSource实现类型进行了深入详尽的介绍，如果它们依然不能满足项目中的需求，我们还可以通过自定义IConfigurationSource实现类型来支持我们希望的配置源。就配置数据的持久化方式来说，将配置存储在数据库中应该是一种常见的方式。接下来我们会创建一个针对数据库的IConfigurationSource实现类型，它采用Entity Framework Core来完成数据库的存取操作。 阅读全文

摘要： XML也是一种常用的配置定义形式，它对数据的表达能力甚至强于JSON，几乎所有类型的数据结构都可以通过XML表示出来。当我们通过一个XML元素表示一个复杂对象的时候，对象的数据成员定义成当前XML元素的子元素。虽然XML对数据结构的表达能力总体要强于JSON，但是作为配置模型的数据来源却有自己的局限性，比如它们对集合的表现形式有点不尽如人意。 阅读全文

摘要： 物理文件是我们最常用到的原始配置载体，而最佳的配置文件格式主要有三种，它们分别是JSON、XML和INI，对应的配置源类型分别是JsonConfigurationSource、XmlConfigurationSource和IniConfigurationSource，它们具有如下一个相同的基类FileConfigurationSource。 阅读全文

摘要： .NET Core采用的这个全新的配置模型的一个主要的特点就是对多种不同配置源的支持。我们可以将内存变量、命令行参数、环境变量和物理文件作为原始配置数据的来源。如果采用物理文件作为配置源，我们可以选择不同的格式(比如XML、JSON和INI等)。如果这些默认支持的配置源形式还不能满足你的需求，我们还可以通过注册自定义IConfigurationSource的方式将其他形式数据作为配置来源。 阅读全文

摘要： 在《配置模型总体设计》介绍配置模型核心对象的时候，我们刻意回避了与配置同步相关的API，现在我们利用一个独立文章来专门讨论这个话题。配置的同步涉及到两个方面：第一，对原始的配置源实施监控并在其发生变化之后重新加载配置；第二，配置重新加载之后及时通知应用程序进而使应用能够及时使用最新的配置。 阅读全文

摘要： 虽然应用程序可以直接利用通过IConfigurationBuilder对象创建的IConfiguration对象来提取配置数据，但是我们更倾向于将其转换成一个POCO对象，以面向对象的方式来使用配置，我们将这个转换过程称为配置绑定。 阅读全文

摘要： 配置的编程模型涉及到三个核心对象，分别通过三个对应的接口（IConfiguration、IConfigurationSource和IConfigurationBuilder）来表示。如果从设计层面来审视背后的配置模型，还缺少另一个名通过IConfigurationProvider接口表示的核心对象。总的来说，配置模型由这四个核心对象组成 阅读全文

摘要： 提到“配置”二字，我想绝大部分.NET开发人员脑海中会立即浮现出两个特殊文件的身影，那就是我们再熟悉不过的app.config和web.config，多年以来我们已经习惯了将结构化的配置定义在这两个XML格式的文件之中。到了.NET Core的时代，很多我们习以为常的东西都发生了改变，其中就包括定义配置的方式。总的来说，新的配置系统显得更加轻量级，并且具有更好的扩展性，其最大的特点就是支持多样化的数据源。我们可以采用内存的变量作为配置的数据源，也可以将配置定义在持久化的文件甚至数据库中。在对配置系统进行系统介绍之前，我们先从编程的角度来体验一下全新的配置读取方式。 阅读全文

摘要： 提到“配置”二字，我想绝大部分.NET开发人员脑海中会立即浮现出两个特殊文件的身影，那就是我们再熟悉不过的app.config和web.config，多年以来我们已经习惯了将结构化的配置定义在这两个XML格式的文件之中。到了.NET Core的时代，很多我们习以为常的东西都发生了改变，其中就包括定义配置的方式。总的来说，新的配置系统显得更加轻量级，并且具有更好的扩展性，其最大的特点就是支持多样化的数据源。我们可以采用内存的变量作为配置的数据源，也可以将配置定义在持久化的文件甚至数据库中。在对配置系统进行系统介绍之前，我们先从编程的角度来体验一下全新的配置读取方式。 阅读全文

摘要： 标题反映的是上周五一个同事咨询我的问题，我觉得这是一个很好的问题。这个问题有助于我们深入理解依赖注入框架在ASP.NET Core中的应用，以及服务实例的生命周期。 阅读全文

摘要： 一个物理文件可以直接作为资源内嵌到编译生成的程序集中。借助于EmbeddedFileProvider，我们可以采用统一的编程方式来读取内嵌的资源文件，该类型定义在 “Microsoft.Extensions.FileProviders.Embedded”这个NuGet包中。在正式介绍EmbeddedFileProvider之前，我们必须知道如何将一个项目文件作为资源内嵌入到编译生成的程序集中。 阅读全文

摘要： ASP.NET Core应用中使用得最多的还是具体的物理文件，比如配置文件、View文件以及作为Web资源的静态文件。物理文件系统由定义在NuGet包“Microsoft.Extensions.FileProviders.Physical”中的PhysicalFileProvider来构建。我们知道System.IO命名空间下定义了一整套针操作物理目录和文件的API，实际上PhysicalFileProvider最终也是通过调用这些API来完成相关的IO操作。 阅读全文

摘要： 在《抽象的“文件系统”》中，我们通过几个简单的实例演示从编程的角度对文件系统做了初步的体验，接下来我们继续从设计的角度来进一步认识它。这个抽象的文件系统以目录的形式来组织文件，我们可以利用它读取某个文件的内容，还可以对目录或者文件实施监控并及时得到变化的通知。 阅读全文

摘要： ASP.NET Core应用 具有很多读取文件的场景，比如配置文件、静态Web资源文件（比如CSS、JavaScript和图片文件等）以及MVC应用的View文件，甚至是直接编译到程序集中的内嵌资源文件。这些文件的读取都需要使用到一个IFileProvider对象。IFileProvider对象构建了一个抽象的文件系统，我们不仅可以利用它提供的统一API来读取各种类型的文件，还能及时监控目标文件的变化。 阅读全文

摘要： .NET Core具有一个承载（Hosting）系统，承载需要在后台长时间运行的服务，一个ASP.NET Core应用仅仅是该系统承载的一种服务而已。承载系统总是采用依赖注入的方式来消费它在服务承载过程所需的服务。对于承载系统来说，原始的服务注册总是体现为一个IServiceCollection集合，最终的依赖注入容器则体现为一个IServiceProvider对象，如果要将第三方依赖注入框架整合进来，就需要利用它们解决从IServiceCollection集合到IServiceProvider对象之间的适配问题。 阅读全文

摘要： 《服务注册》、《服务消费》和《生命周期》主要从实现原理的角度对.NET Core的依赖注入框架进行了介绍，接下来更进一步，看看该框架的总体设计和实现。在过去的多个版本更迭过程中，依赖注入框架的底层实现一直都在发生改变，加上底层的涉及的大都是内容接口和类型，所以我们不打算涉及太过细节的层面。 阅读全文

摘要： 生命周期决定了IServiceProvider对象采用怎样的方式提供和释放服务实例。虽然不同版本的依赖注入框架针对服务实例的生命周期管理采用了不同的实现，但总的来说原理还是类似的。在我们提供的依赖注入框架Cat中，我们已经模拟了三种生命周期模式的实现原理，接下来我们结合“服务范围”的概念来对这个话题做进一步讲述。 阅读全文

摘要： 包含服务注册信息的IServiceCollection集合最终被用来创建作为依赖注入容器的IServiceProvider对象。当需要消费某个服务实例的时候，我们只需要指定服务类型调用IServiceProvider的GetService方法即可，IServiceProvider对象就会根据对应的服务注册提供所需的服务实例。 阅读全文

摘要： 通过《利用容器提供服务》我们知道作为依赖注入容器的IServiceProvider对象是通过调用IServiceCollection接口的扩展方法BuildServiceProvider创建的，IServiceCollection对象是一个存放服务注册信息的集合。在《一个迷你版DI框架》中创建的Cat框架中的服务注册是通过类型ServiceRegistry表示的，在.NET Core依赖注入框架中，与之对应的类型是ServiceDescriptor。 阅读全文

摘要： 毫不夸张地说，整个ASP.NET Core框架是建立在依赖注入框架之上的。ASP.NET Core应用在启动时构建管道以及利用该管道处理每个请求过程中使用到的服务对象均来源于依赖注入容器。该依赖注入容器不仅为ASP.NET Core框架自身提供必要的服务，同时也是应用程序的服务提供者，依赖注入已经成为了ASP.NET Core应用的基本编程模式。 阅读全文

摘要： 注册拦截器旨在解决如何将拦截器应用到目标方法的问题。在我看来，针对拦截器的注册应该是明确而精准的，也就是我们提供的注册方式应该让拦截器准确地应用到期望的目标方法上，不能多也不能少。Dora.Interception只提供两种严谨的拦截器注册方式，一种前面介绍的针对特性标注的方式，另一种就是本篇介绍的针对策略的方式。 阅读全文

摘要： 按照单一职责的原则，拦截器只负责需要的拦截操作的执行，至于它采用何种方式应用到目标方法上，以及它在整个拦截器管道中的位置则属于“拦截器注册”的范畴。Dora.Interception提供了几种典型的注册方法，用户也可以根据自己的需求实现自己的注册方式。 阅读全文

摘要： 对于所有的AOP框架来说，多个拦截器最终会应用到某个方法上。这些拦截器按照指定的顺序构成一个管道，管道的另一端就是针对目标方法的调用。从设计角度来将，拦截器和中间件本质是一样的，那么我们可以按照类似的模式来设计拦截器。 阅读全文

摘要： 和所有的AOP框架一样，我们必须将正常的方法调用进行拦截，才能将应用到当前方法上的所有拦截器纳入当前调用链。Dora.Interception采用IL Eimit的方式实现对方法调用的拦截，接下来我们就来聊聊大致的实现原理。 阅读全文

摘要： 在前面的章节中，我们从纯理论的角度对依赖注入进行了深入论述，我们接下来会对.NET Core依赖注入框架进行单独介绍。为了让读者朋友能够更好地理解.NET Core依赖注入框架的设计与实现，我们按照类似的原理创建了一个简易版本的依赖注入框架，也就是我们在前面多次提及的Cat。 阅读全文

摘要： IoC主要体现了这样一种设计思想：通过将一组通用流程的控制权从应用转移到框架之中以实现对流程的复用，并按照“好莱坞法则”实现应用程序的代码与框架之间的交互。我们可以采用若干设计模式以不同的方式实现IoC，比如我们在前面介绍的模板方法、工厂方法和抽象工厂，接下来我们介绍一种更有价值的IoC模式：依赖注入（DI：Dependency Injection）。 阅读全文