摘要： ASP.NET的路由是通过EndpointRoutingMiddleware和EndpointMiddleware这两个中间件协作完成的，它们在ASP.NET平台上具有举足轻重的地位，MVC和gRPC框架，Dapr的Actor和发布订阅编程模式都建立在路由系统之上。Minimal API更是将提升到了前所未有的高度，上一篇通过9个实例演示了基于路由的REST API开发，本篇演示一些“高阶”的用法。 阅读全文

摘要： ASP.NET的路由是通过EndpointRoutingMiddleware和EndpointMiddleware这两个中间件协作完成的，它们在ASP.NET平台上具有举足轻重的地位，MVC和gRPC框架，Dapr的Actor和发布订阅编程模式都建立在路由系统之上。Minimal API更是将提升到了前所未有的高度，是我们直接在路由系统基础上定义REST API 阅读全文

摘要： 通过HTTP请求获取的Web资源很多都来源于存储在服务器磁盘上的静态文件。对于ASP.NET应用来说，如果将静态文件存储到约定的目录下，绝大部分文件类型都是可以通过Web的形式对外发布的。“Microsoft.AspNetCore.StaticFiles” 这个NuGet包中提供了三个用来处理静态文 阅读全文

摘要： P5第2段 原文：由于创建的是一个针对 ASP.NET Core 的可执行控制台应用，所以将 OutputType 和 TargetFramework 的属性分别设置为“Exe”和“net6.0”。 改为：由于创建的是一个针对 .NET 6的可执行控制台应用，所以将 OutputType 和 Tar 阅读全文

摘要： 天下大势，分久必合，合久必分”，ASP.NET应用通过GenericWebHostService这个承载服务被整合到基于IHostBuilder/IHost的服务承载系统中之后，也许微软还是意识到Web应用和后台服务的承载方式还是应该加以区分，于是推出了基于WebApplicationBuilder/WebApplication的承载方式。我们可以将其称为第三代承载模式，它有一个官方的名称叫做“Minimal API”。Minimal API同样面临向后兼容的问题，而且这次需要同时兼容前面两代承载模式，所以我们会发现“上篇”中提到的一系列初始化操作有了更多实现方式。 阅读全文

摘要： 作为《ASP.NET Core 3 框架揭秘》的升级版，《ASP.NET Core 6框架揭秘》不仅针对ASP.NET Core 6的新特性进行了修订，并添加了若干原来没有的内容。对于ASP.NET Core 框架来说，最为核心的莫过于中间件管道的构建，这也是《ASP.NET Core 6 框架揭秘 阅读全文

摘要： 在ASP.NET Core的发展历史上先后出现了三种应用承载的编程方式，而且后一种编程模式都提供了针对之前编程模式的全部或者部分兼容，这就导致了一种现象：相同的更能具有N种实现方式。对这个发展历程不是特别了解的读者会有很多疑问？为什么这么多不同的编程模式都在作同一件事？它们之间的有什么差别之处？为什么有的API在最新的Minimal API又不能用了呢？ 阅读全文

摘要： Dapr 被设计成一个面向开发者的企业级微服务编程平台，它独立于具体的技术平台，可以运行在“任何地方”。Dapr本身并不提供“基础设施（infrastructure）”，而是利用自身的扩展来适配具体的部署环境。就目前的状态来说，如果希望真正将原生的Dapr应用与生产，只能部署在K8S环境下。虽然Dapr也提供针对Hashicorp Consul的支持，但是目前貌似没有稳定的版本支持。Kubernetes对于很多公司并非“标配”，由于某些原因，它们可以具有一套自研的微服务平台或者弹性云平台，让Dapr与之适配可能更有价值。 阅读全文

摘要： 多年之前利用IL Emit写了一个名为Dora.Interception的AOP框架。前几天利用Roslyn的Source Generator对自己为公司写的一个GraphQL框架进行改造，性能得到显著的提高，觉得类似的机制同样可以用在AOP框架上，实验证明这样的实现方式不仅仅极大地改善性能（包括执行耗时和GC内存分配），而且让很多的功能特性变得简单了很多。 阅读全文

摘要： 本系列前面的五篇文章主要介绍Dora.Interception（github地址，觉得不错不妨给一颗星）的编程模式以及对它的扩展定制，现在我们来聊聊它的设计和实现原理。（拙著《ASP.NET Core 6框架揭秘》6折优惠，首印送签名专属书签）。 阅读全文

摘要： Dora.Interception提供了两种拦截器注册方式，一种是利用标注在目标类型、属性和方法上的InterceptorAttribute特性，另一种采用基于目标方法或者属性的调用表达式。通过提供的扩展点，我们可以任何我们希望的拦截器注册方式。（拙著《ASP.NET Core 6框架揭秘》6折优惠，首印送签名专属书签） 阅读全文

摘要： ASP.NET Core 6框架揭秘（上下册）》主要介绍 ASP.NET Core 框架的核心技术部分，即由一个服务器和若干中间件构建的管道。本书共分为 5 篇：“第 1 篇 初识编程（第 1 章）”列举一系列极简的实例为读者提供基本的编程体验，“第 2 篇 基础框架（第 2～13 章）”主要介绍了一系列支撑 ASP.NET Core 的基础框架，“第 3 篇 承载系统（第 14～17章）”主要介绍了 ASP.NET Core 应用的承载流程，“第 4 篇 服务器概述（第 18 章）”列举一系列常见的服务器类型并对它们进行了比较，“第 5 篇 中间件（第 19～30 章）”系统地介绍了一系列预定义的中间件。 阅读全文

摘要： 基于特性标注的拦截器注册方式仅限于将拦截器应用到自己定义的类型上，对于第三方提供的类型就无能为力了。拦截器注册本质上建立拦截器与一个或者多个目标方法之间的映射，所以最笨的方式就是利用反射的方式得到表示目标方法的MethodInfo对象，并将它与对应的拦截器关联在一起。这种方式虽然能够解决问题，但是编程体验很差。本篇介绍的基于表达式的拦截器注册方式利用针对目标方法或者属性的调用表达式，以一种强类型的方式获取到目标方法，极大地改善了编程体验。 阅读全文

摘要： 在Dora.Interception（github地址，觉得不错不妨给一颗星）中按照约定方式定义的拦截器可以采用多种方式注册到目标方法上。本篇文章介绍最常用的基于“特性标注”的拦截器注册方式，下一篇会介绍另一种基于（Lambda）表达式的注册方式。如果原生定义的这两种注册方式不能满足要求，利用框架提供的扩展，我们可以完成任何你想要的拦截器注册手段。（ 阅读全文

摘要： Dora.Interception有别于其他AOP框架的最大的一个特点就是采用针对“约定”的拦截器定义方式（拙著《ASP.NET Core 6框架揭秘》于日前上市，加入读者群享6折优惠） 阅读全文

摘要： 多年之前利用IL Emit写了一个名为Dora.Interception（github地址，觉得不错不妨给一颗星）的AOP框架。前几天利用Roslyn的Source Generator对自己为公司写的一个GraphQL框架进行改造，性能得到显著的提高，觉得类似的机制同样可以用在AOP框架上，实验证明这样的实现方式不仅仅极大地改善性能（包括执行耗时和GC内存分配），而且让很多的功能特性变得简单了很多 阅读全文

摘要： 作为ASP.NET CORE请求处理管道的“龙头”的服务器负责监听和接收请求并最终完成对请求的响应。它将原始的请求上下文描述为相应的特性（Feature），并以此将HttpContext上下文创建出来，中间件针对HttpContext上下文的所有操作将借助于这些特性转移到原始的请求上下文上。除了我们最常用的Kestrel服务器，ASP.NET CORE还提供了其他类型的服务器。 阅读全文

摘要： 如果我们只需要将ASP.NET CORE应用部署到Windows环境下，并且希望获得更好的性能，那么我们选择的服务器类型应该是HTTP.SYS。Windows环境下任何针对HTTP的网络监听器/服务器在性能上都无法与HTTP.SYS比肩。 阅读全文

摘要： KestrelServer最大的优势体现在它的跨平台的能力，如果ASP.NET CORE应用只需要部署在Windows环境下，IIS也是不错的选择。ASP.NET CORE应用针对IIS具有两种部署模式，它们都依赖于一个IIS针对ASP.NET CORE Core的扩展模块。 阅读全文

摘要： 和所有的服务器一样，KestrelServer最终需要解决的是网络传输的问题。在《网络连接的创建》，我们介绍了KestrelServer如何利用连接接听器的建立网络连接，并再次基础上演示了如何直接利用建立的连接接收请求和回复响应。本篇更进一步，我们根据其总体设计，定义了迷你版的KestrelServer让读者看看这个重要的服务器大体是如何实现的。 阅读全文

摘要： 《注册监听终结点（Endpoint）》已经详细讲述了如何使用KestrelServer，现在我们来简单聊聊这种处理器的总体设计和实现原理。当KestrelServer启动的时候，注册的每个终结点将转换成对应的“连接监听器”，后者在监听到初始请求时会创建“连接”，请求的接收和响应的回复都在这个连接中完成。 阅读全文

摘要： 具有跨平台能力的KestrelServer是最重要的服务器类型。针对KestrelServer的设置均体现在KestrelServerOptions配置选项上，注册的终结点是它承载的最重要的配置选项。这里所谓的终结点（Endpoint）与“路由”介绍的终结点不是一回事，这里表示的就是服务器在监听请求时绑定的网络地址，对应着一个System.Net.Endpoint对象。 阅读全文

摘要： Task对于.NET的重要性毋庸置疑。通过最近的一些面试经历，发现很多人对与Task及其调度机制，以及线程和线程池之间的关系并没有清晰的认识。本文采用最简单的方式模拟了Task的实现，旨在说明Task是什么？它是如何被调度执行的？ 阅读全文

摘要： 学习ASP.NET Core框架最有效的方式就是按照它的原理“再造”一个框架，了解服务器的本质最好的手段就是试着自定义一个服务器。现在我们自定义一个真正的服务器 阅读全文

摘要： Minimal API仅仅是在基于IHost/IHostBuilder的服务承载系统上作了小小的封装而已，它利用WebApplication和WebApplicationBuilder这两个类型提供了更加简洁的API，同时提供了与现有API的兼容。要成分理解Minimal API的实现原理 阅读全文

摘要： 很多人可能对ASP.NET Core框架自身记录的诊断日志并不关心，其实这些日志对纠错排错和性能监控提供了很有用的信息。如果需要创建一个APM（Application Performance Management）系统来监控ASP.NET Core应用处理请求的性能及出现的异常，我们完全可以将HostingApplication对象记录的日志作为收集的原始数据。实际上，目前很多APM（如OpenTelemetry.NET 、Elastic APM和SkyWalking APM等）针对都是利用这种方式收集分布式跟踪日志的。 阅读全文

摘要： 与服务注册一样，针对配置的设置同样可以采用三种不同的编程模式。第一种是利用WebApplicationBuilder的Host属性返回的IHostBuilder对象，它可以帮助我们设置面向宿主和应用的配置。IWebHostBuilder接口上面同样提供了一系列用来对配置进行设置的方法，我们可以将这些方法应用到WebApplicationBuilder的WebHost属性返回的IWebHostBuilder对象上。不过还是那句话，既然推荐使用Mininal API，最好还是采用最新的编程方式。 阅读全文

摘要： ASP.NET Core的请求处理管道由一个服务器和一组中间件组成，位于 “龙头” 的服务器负责请求的监听、接收、分发和最终的响应，针对请求的处理由后续的中间件来完成。中间件最终体现为一个Func委托，但是我们具有不同的定义和注册方式。 阅读全文

摘要： ASP.NET Core应用本质上就是一个由中间件构成的管道，承载系统将应用承载于一个托管进程中运行起来，其核心任务就是将这个管道构建起来。从设计模式的角度来讲，“管道”是构建者（Builder）模式最典型的应用场景，所以ASP.NET Core先后采用的三种承载方式都是采用这种模式。 阅读全文

摘要： 借助 .NET提供的服务承载（Hosting）系统，我们可以将一个或者多个长时间运行的后台服务寄宿或者承载我们创建的应用中。任何需要在后台长时间运行的操作都可以定义成标准化的服务并利用该系统来承载，ASP.NET Core应用最终也体现为这样一个承载服务。 阅读全文

摘要： 借助 .NET提供的服务承载（Hosting）系统，我们可以将一个或者多个长时间运行的后台服务寄宿或者承载我们创建的应用中。任何需要在后台长时间运行的操作都可以定义成标准化的服务并利用该系统来承载，ASP.NET Core应用最终也体现为这样一个承载服务。 阅读全文

摘要： 《数据加解密与哈希》演示了“数据保护”框架如何用来对数据进行加解密，而“数据保护”框架的核心是“密钥管理”。数据保护框架以XML的形式来存储密钥，默认的IKeyManager实现类型为XmlKeyManager。接下来我们通过模拟代码和实例演示的形式来介绍一下XmlKeyManager对象针对密钥的创建、撤销和回收的实现原理。( 阅读全文

摘要： 数据保护（Data Protection）框架旨在解决数据在传输与持久化存储过程中的一致性（Integrity）和机密性（confidentiality）问题，前者用于检验接收到的数据是否经过篡改，后者通过对原始的数据进行加密以避免真实的内容被人窥视。数据保护是支撑ASP.NET身份认证的一个重要的基础框架，同时也可以作为独立的框架供我们使用。( 阅读全文

摘要： 我们知道ASP.NET的核心就是由中间件组成的请求处理管道，HttpClient也采用了类似的设计。HttpClient管道由一组HttpMessageHandler对象构成，这些HttpMessageHandler相当于ASPNET的中间件。如下这些示例演示帮助我们更清楚地认识HttpMessageHandler处理管道。 阅读全文

摘要： 在一个采用依赖注入框架的应用中，我们一般不太推荐利用手工创建的HttpClient对象来进行HTTP调用，使用的HttpClient对象最好利用注入的IHttpClientFactory工厂来创建。前者引起的问题，以及后者带来的好处，将通过如下这几个演示程序展现出来。IHttpClientFactory类型由“Microsoft.Extensions.Http”这个NuGet包提供，“Microsoft.NET.Sdk.Web”SDK具有该包的默认引用。 阅读全文

摘要： .NET提供了两个独立的缓存框架，一个是针对本地内存的缓存，另一个是针对分布式存储的缓存。前者可以在不经过序列化的情况下直接将对象存储在应用程序进程的内存中，后者则需要将对象序列化成字节数组并存储到一个独立的“中心数据库”。对于分布式缓存，.NET提供了针对Redis和SQL Server的原生支持 阅读全文

摘要： 针对控制台的ILogger实现类型为ConsoleLogger，对应的ILoggerProvider实现类型为ConsoleLoggerProvider，这两个类型都定义在 NuGet包“Microsoft.Extensions.Logging.Console”中。ConsoleLogger要将一条日志输出到控制台上，首选要解决的是格式化的问题，具体来说是如何将日志消息的内容荷载和元数据（类别、等级和事件ID等）格式化成呈现在控制台上的文本。针对日志的格式化由ConsoleFormatter对象来完成。 阅读全文

摘要： 为了对各种日志框架进行整合，微软创建了一个用来提供统一的日志编程模式的日志框架。《日志的基本编程模式》以实例演示的方式介绍了日志的基本编程模式，现在我们来补充几种“进阶”用法。 阅读全文

摘要： 《诊断跟踪的几种基本编程方式》介绍了四种常用的诊断日志框架。其实除了微软提供的这些日志框架，还有很多第三方日志框架可供我们选择，比如Log4Net、NLog和Serilog 等。虽然这些框架大都采用类似的设计，但是它们采用的编程模式具有很大的差异。为了对这些日志框架进行整合，微软创建了一个用来提供统一的日志编程模式的日志框架。( 阅读全文

摘要： 一个好的程序员能够在系统出现问题之后马上定位错误的根源并找到正确的解决方案，一个更好的程序员能够根据当前的运行状态预知未来可能发生的问题，并将问题扼杀在摇篮中。诊断跟踪能够帮助我们有效地纠错和排错《几种基本诊断跟踪编程方式》提供了7个实例演示了针对TraceSource、EventSource和DiagnosticSource的基本用法，其实它们还具有一个更“高级”的使用方式。( 阅读全文