摘要： 之前參與一個機票價格計算的項目，為他們設計了基本的處理流程，但是由于整個計算流程相當復雜，而且變化非常頻繁，導致日常的修改、維護和升級也變得越來越麻煩，當我后來再接手的時候已經看不懂計算邏輯了。為了解決這個問題，我借鑒了“工作流”的思路，試圖將整個計算過程設計成一個工作流。但是我又不想引入一個獨立的工作流引擎，于是寫了一個名為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的擴展模塊。 閱讀全文