摘要： 之前参与一个机票价格计算的项目，为他们设计了基本的处理流程，但是由于整个计算流程相当复杂，而且变化非常频繁，导致日常的修改、维护和升级也变得越来越麻烦，当我后来再接手的时候已经看不懂计算逻辑了。为了解决这个问题，我借鉴了“工作流”的思路，试图将整个计算过程设计成一个工作流。但是我又不想引入一个独立的工作流引擎，于是写了一个名为Pipelines的框架。 阅读全文

摘要： 我在面试的时候经常会问一个问题：“谈谈值类型和引用的区别”。对于这个问题，绝大部分人都只会给我两个简洁的答案：“值类型分配在栈中，引用类型分配在堆中”，“在默认情况下，值类型参数传值（拷贝），引用类型参数传引用”。其实这个问题有很大的发挥空间，如果能够从内存布局、GC、互操作、跨AppDomain传 阅读全文

摘要： ASP.NET应用并没有对如何定义授权策略做硬性规定，但是针对角色的授权策略依然是最常用的。角色（或者用户组）实际上就是对一组权限集的描述，将一个用户添加到某个角色之中就是为了将对应的权限赋予该用户。在《使用最简洁的代码实现登录、认证和注销》中，我们提供了一个用来演示登录、认证和注销的程序，现在我们在此基础上添加基于“角色授权的部分”。 阅读全文

摘要： 认证是一个确定请求访问者真实身份的过程，与认证相关的还有其他两个基本操作——登录和注销。ASP.NET Core利用AuthenticationMiddleware中间件完成针对请求的认证，并提供了用于登录、注销以及“质询”的API，本篇文章利用它们使用最简单的代码实现这些功能。 阅读全文

摘要： 承载ASP.NET应用的服务器资源总是有限的，短时间内涌入过多的请求可能会瞬间耗尽可用资源并导致宕机。为了解决这个问题，我们需要在服务端设置一个阀门将并发处理的请求数量限制在一个可控的范围，即使会导致请求的延迟响应，在极端的情况会还不得不放弃一些请求。ASP.NET应用的流量限制是通过ConcurrencyLimiterMiddleware中间件实现的。 阅读全文

摘要： 在HTTP的语义中，重定向一般指的是服务端通过返回一个状态码为3XX的响应促使客户端像另一个地址再次发起请求，本章将此称为“客户端重定向“。既然有客户端重定向，自然就有服务端重定向，本章所谓的服务端重定向指的是在服务端通过改变请求路径将请求导向另一个终结点。ASP.NET下的重定向是通过RewriteMiddleware中间件实现的。 阅读全文

摘要： 在讨论.NET的类型系统的时候，我们经常提到“基元类型（Primitive Type）”的概念，我发现很多人并没有真正理解基元类型就究竟包含哪些（比如很多人觉得字符串是基元类型）。除了明确界定基元类型外，本篇文章还会简单介绍额外两种关于类型的概念——Unmananged类型和Blittable类型。 阅读全文

摘要： 在《如何计算一个实例占用多少内存？》中我们知道一个值类型或者引用类型的实例在内存中占多少字节。如果我们知道这段连续的字节序列的初始地址，我们就能够将代表该实例的字节内容读取出来。在接下来的内容中，我们将利用一个简单的方法输出指定实例的字节序列，并此次分析值类型和引用类型实例在内存的布局。 一、读取实 阅读全文

摘要： 我们都知道CPU和内存是程序最为重要的两类指标，那么有多少人真正想过这个问题：一个类型（值类型或者引用类型）的实例在内存中究竟占多少字节？我们很多人都回答不上来。其实C#提供了一些用于计算大小的操作符和API，但是它们都不能完全解决我刚才提出的问题。本文提供了一种计算值类型和引用类型实例所占内存字节数量的方法。 阅读全文

摘要： HTTPS是确保传输安全最主要的手段，并且已经成为了互联网默认的传输协议。不知道读者朋友们是否注意到当我们利用浏览器（比如Chrome）浏览某个公共站点的时候，如果我们输入的是一个HTTP地址，在大部分情况下浏览器会自动重定向到对应HTTPS地址。这一特性源于浏览器和服务端针对HSTS（HTTP Strict Transport Security）这一HTTP规范的支持。ASP.NET利用HstsMiddleware和HttpsRedirectionMiddleware这两个中间件提供了对HSTS的实现。 阅读全文

摘要： 了解OpenTelemetry的朋友应该知道，为了将率属于同一个请求的多个操作（Span）串起来，上游应用会生成一个唯一的TraceId。在进行跨应用的Web调用时，这个TraceId和代表跟踪操作标识的SpanID一并发给目标应用。其实我们的应用也可能会使用到分布式跟踪这种类似的功能，我们需要在某个应用中添加一些“埋点”，当它调用另一个应用时，这些埋点会自动添加到请求的报头集合中，从而实现在整个调用链中自动传递 阅读全文

摘要： 我们经常会遇到这样的数据处理应用场景：我们利用一个组件实时收集外部交付给它的数据，并由它转发给一个外部处理程序进行处理。考虑到性能，它会将数据存储在本地缓冲区，等累积到指定的数量后打包发送；考虑到实时性，数据不能在缓冲区存太长的时间，必须设置一个延时时间，一旦超过这个时间，缓冲的数据必须立即发出去。看似简单的需求，如果需要综合考虑性能、线程安全、内存分配，要实现起来还真有点麻烦，本文提供一种简单的实现方式。 阅读全文

摘要： Task承载的操作需要被调度才能被执行，由于.NET默认采用基于线程池的调度器，所以Task默认在线程池线程中执行。但是有的操作并不适合使用线程池，比如我们在一个ASP.NET Core应用中承载了一些需要长时间执行的后台操作，由于线程池被用来处理HTTP请求，如果这些后台操作也使用线程池来调度，就会造成相互影响。在这种情况下，使用独立的一个或者多个线程来执行这些后台操作可能是一个更好的选择。 阅读全文

摘要： C# 11带来了一个我期待已久的特性——接口方法。我们知道接口是针对契约的定义，但是一直以来它只能定义一组“实例”的契约，而不能定义类型（的静态成员）的契约，因为定义在接口中的方法只能是实例方法。由于缺乏针对“类型契约”的支持，我们在设计一些框架或者类库的时候，只能采用“按照约定”的设计，比如ASP.NET Core Minimal API针对参数的绑定就是一个典型的案例。 阅读全文

摘要： 在《用最少的代码模拟gRPC四种消息交换模式》中，我使用很简单的代码模拟了gRPC四种消息交换模式（Unary、Client Streaming、Server Streaming和Duplex Streaming），现在我们更近一步，试着使用极简的方式打造一个gRPC框架（github地址）。这个gRPC是对ASP.NET Core gRPC实现原理的模拟，并不是想重新造一个轮子。 阅读全文

摘要： 我们知道，建立在HTTP2/3之上的gRPC具有四种基本的通信模式或者消息交换模式（MEP： Message Exchange Pattern），即Unary、Server Stream、Client Stream和Bidirectional Stream。本篇文章通过4个简单的实例演示它们在.NET平台上的实现原理，源代码从这里查看。 阅读全文

摘要： System.Runtime.CompilerServices命名空间下有4个以“Caller”为前缀命名的Attribute，我们可以将它标注到方法参数上自动获取当前调用上下文的信息，比如当前的方法名、某个参数的表达式、当前源文件的路径，以及当前代码在源文件中的行号。 阅读全文

摘要： 客户端和服务器基于HTTP的消息交换就好比两个完全没有记忆能力的人在交流，每次单一的HTTP事务体现为一次“一问一答”的对话。单一的对话毫无意义，在在同一语境下针对某个主题进行的多次对话才会有结果。会话的目的就是在同一个客户端和服务器之间建立两者交谈的语境或者上下文，ASP.NET Core利用一个名为SessionMiddleware的中间件实现了会话。本篇提供了几个简单的实例来演示如何在一个ASP.NET Core应用中利用会话来存储用户的状态。 阅读全文

摘要： 我们利用ASP.NET开发的大部分API都是为了对外提供资源，对于不易变化的资源内容，针对某个维度对其实施缓存可以很好地提供应用的性能。《内存缓存与分布式缓存的使用》介绍的两种缓存框架（本地内存缓存和分布式缓存）为我们提供了简单易用的缓存读写编程模式，本篇介绍的则是针对针对HTTP响应内容实施缓存，ResponseCachingMiddleware中间件赋予我们的能力。 阅读全文

摘要： NuGet包“Microsoft.AspNetCore.Diagnostics”中提供了几个与异常处理相关的中间件，我们可以利用它们将原生的或者定制的错误信息作为响应内容发送给客户端。《错误页面的N种呈现方式》演示了几个简单的实例使读者大致了解这些中间件的作用，现在我们来演示几个高阶用法。 阅读全文

摘要： 由于ASP.NET是一个同时处理多个请求的Web应用框架，所以在处理某个请求过程中出现异常并不会导致整个应用的中止。出于安全方面的考量，为了避免敏感信息外泄，客户端在默认情况下并不会得到详细的出错信息，这无疑会在开发过程中增加查错和纠错的难度。对于生产环境来说，我们也希望最终用户能够根据具体的错误类型得到具有针对性并且友好的错误消息。ASP.NET提供的相应的中间件可以帮助我们将定制化的错误信息呈现出来。 阅读全文

摘要： 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的扩展模块。 阅读全文