摘要： 如果想体验Linux环境下开发.NET Core应用，我们有多种选择。一种就是在一台物理机上安装原生的Linux，也可以采用虚拟机的形式安装相应的Linux Distribution。对于X64 Windows 10的用户来说，我们有了第三种更为方便快捷的选择，那就是使用Windows 10提供的Linux子系统。 阅读全文

摘要： 除了微软自家的Windows平台， .NET Core针对Mac OS以及各种Linux Distribution（RHEL、Ubuntu、Debian、Fedora、CentOS和SUSE等）都提供了很好的支持。我们先来体验一下使用Mac来开发.NET Core应用， 阅读全文

摘要： 由于ASP.NET Core框架在本质上就是由服务器和中间件构建的消息处理管道，所以在它上面构建的应用开发框架都是建立在某种类型的中间件上，整个ASP.NET Core MVC开发框架就是建立在用来实现路由的EndpointRoutingMiddleware和EndpointMiddleware中间件上。ASP.NET Core MVC利用路由系统为它分发请求，并在此基础上实现针对目标Controller的激活、Action方法的选择和执行，以及最终对于执行结果的响应。在介绍的实例演示中，我们将对上面创建的ASP.NET Core作进一步改造，使之转变成一个MVC应用。 阅读全文

摘要： 我们在《上篇》利用dotnet new命令创建了一个简单的控制台程序，接下来我们将它改造成一个ASP.NET Core应用。一个ASP.NET Core应用构建在ASP.NET Core框架之上，ASP.NET Core框架利用一个消息处理管道完成对HTTP请求的监听、接收、处理和最终的响应。ASP.NET Core管道由一个服务器（Server）和若干中间件（Middleware）构成，当宿主（Host）程序启动之后，管道被构建出来，作为管道“龙头”的服务器开始监听来自客户端的HTTP请求。 阅读全文

摘要： .NET Core带来了全新的开发体验，但开发方式的差异根本不足以成为你快速跨入.NET Core 世界的门槛，因为在.NET Core在很多方面比传统的.NET Framework应用开发要简单。为了消除很多尚未接触过.NET Core的读者对未知世界的恐惧，我们先通过几个简单的Hello World应用让大家感受一下在Windows上的.NET Core全新的开发体验。 阅读全文

摘要： .NET Core正式发布之后，我为.NET Core度身定制的AOP框架Dora.Interception也升级到3.0。这个版本除了升级底层类库（.NET Standard 2.1）之外，我还对它进行大范围的重构甚至重新设计。这次重构大部分是在做减法，其目的在于使设计和使用更加简单和灵活，接下来我们就来体验一下在一个ASP.NET Core应用程序下如何使用Dora.Interception。 阅读全文

摘要： HttpClient在Web调用中具有广泛的应用，而为它添加默认请求头是我们经常遇到的需求，本文介绍4种为HttpClient添加默认请求头的方式。 阅读全文

摘要： 我们知道通过C#编写的.NET程序在编译后会转化成IL Code，在运行时以及时编译的方式转化成机器指令。如果想“篡改”某个方法的实现，要么在JIT之前改变IL代码，要么直接修改最终的机器指令。本文采用第二种解决方案，基本的思路就是将将原方法的机器指令修改为JUMP（对应x86二进制为0xE9）指令实现向目标方法的跳转。 阅读全文

摘要： 《三体》让我们了解了什么是“降维打击”，在软件设计领域很多时候需要反其道而行。对于某个问题，如果不能有效的解决，可以考虑是否可以上升一个维度，从高维视角审视问题往往可以找到捷径。软件设计是抽象的艺术，“升维打击”实际上就是“维度”层面的抽象罢了。 阅读全文

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

摘要： 这里所谓的与第三方AOP框架的整合不是说改变Dora.Interception现有的编程，而是恰好相反，即在不改变现有编程模式下采用第三方AOP框架或者自行实现的拦截机制。虽然我们默认提供基于IL Emit实现方式，并且对IL指令进行了深度的优化，但是如果我们真的具有更好的选择，我们可以通过简单的扩展完成对底层拦截机制改变 阅读全文

摘要： 对于.NET Core程序开发来说，依赖注入已经成为无处不在并且“深入骨髓”的东西，不论是在进行业务应用的开发，还是进行基础组件的开发，依赖注入是实现“松耦合”最为理想的方式（没有之一）,所以Dora.Interception必须将两者无缝地集成在一起。 阅读全文

摘要： 在《以约定的方式定义拦截器》中，我们通过对拦截器的介绍了Dora.Interception的两种拦截机制，即针对接口的“实例拦截”针对虚方法的“类型拦截”。我们介绍了拦截器的本质以及基于约定的拦截器定义方式，接下来我们将着重关注拦截器的应用问题。 阅读全文

摘要： 上一篇《更加简练的编程体验》提供了最新版本的Dora.Interception代码的AOP编程体验，接下来我们会这AOP框架的编程模式进行详细介绍，本篇文章着重关注的是拦截器的定义。采用“基于约定”的Interceptor定义方式是Dora.Interception区别于其他AOP框架的一个显著特征，要了解拦截器的编程约定，就得先来了解一下Dora.Interception中针对方法调用的拦截是如何实现的。 阅读全文

摘要： 很久之前开发了一个名为Dora.Interception的开源AOP框架，最近对它作了一些改进。这个新版本对拦截器的定义和应用提供了更加简单的定义方式，同时对扩展性方法作了较大的改进，接下来我们通过一个简单实例来体验一下。 阅读全文

摘要： TechEmpower在10月30发布最新一轮（Round 17）针对“Web Framework Benchmarks”的性能测试报告，ASP.NET Core依旧表现不俗，在一些指标上甚至是碾压其他主流Web框架。为此我们做了一个简单的统计，看看ASP.NET Core和其他我们熟悉的Web框架，比如Servlet、Go、NodeJS和PHP之间的差距。 阅读全文

摘要： 之前一段时间都在个人公众号账号“大内老A”发布关于ASP.NET Core的系列文章，很多人留言希望能够同步到这里，所以在这里 对这些文章做一个汇总，以便于PC端阅读。如果说微软官方文档主要关于ASP.NET Core的编程模式的话，我这个系列则主要关注整个ASP.NET Core的设计思想和实现原理。我希望这个系列为致力于深入学习ASP.NET Core的人提供一个全面、系统而深入的知识库。为了确保本系列的纯粹性，这个系列旨在关注ASP.NET Core以中间件管道核心的框架，不会涉及建立在它之上的编程模型（比如ASP.NET Core MVC）。 阅读全文

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

摘要： 包含服务注册信息的IServiceCollection对象最终被用来创建作为DI容器的IServiceProvider对象。服务注册就是创建出现相应的ServiceDescriptor对象并将其添加到指定IServiceCollection集合对象中的过程。 阅读全文

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

摘要： 名为Cat的DI框架。在《依赖注入[4]: 创建一个简易版的DI框架[上篇]》中我们介绍了Cat的基本编程模式，接下来我们就来聊聊Cat的设计和实现。 阅读全文

摘要： 本系列文章旨在剖析.NET Core的依赖注入框架的实现原理，到目前为止我们通过三篇文章（《控制反转》、《基于IoC的设计模式》和《 依赖注入模式》）从纯理论的角度对依赖注入进行了深入论述，为了让读者朋友能够更好地理解.NET Core的依赖注入框架的设计思想和实现原理，我们创建了一个简易版本的DI框架，也就是我们在前面文章中多次提及的Cat。我们会上下两篇来介绍这个被称为为Cat的DI框架。 阅读全文

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

摘要： 前几天对Dora.Interception作了简单的重构，想提供C#脚本来定义Interception Policy，毫无疑问微软提供的编译平台Roslyn使C#脚本话提供了支持。但是没有想到随便尝试了一个简单的功能就出现了问题，我个人觉得这应该是Roslyn的Bug。但是Roslyn经历了这么多次版本的迭代还出现如此低级的错误，实在有点说不过去。 阅读全文

摘要： 正如我们在《控制反转》提到过的，很多人将IoC理解为一种“面向对象的设计模式”，实际上IoC自身不仅与面向对象没有必然的联系，它也算不上是一种设计模式。一般来讲，设计模式提供了一种解决某种具体问题的方案，但是IoC既没有一个针对性的问题领域，其自身没有提供一种可实施的解决方案，所以我更加倾向于将IoC视为一种设计原则。实际上很多我们熟悉的设计模式背后采用了IoC原则，接下来我们就来介绍几种典型的“设计模式”。 阅读全文

摘要： 软件设计中由一些所谓的理念都没有一个明确的定义，比如之前流行的SOA和现在炒的火热的微服务（Micro Service）和无服务器（Serverless），我们都不能通过一个明确的“内涵”给它们一个准确地定义，只能从“外延”上描述这些架构设计应该具有怎样的特性。正因为无法给出一个明确的界定，造成了人们针对同一个概念出现了很多不同的理解。针对IoC也是这种情况，所以本章所诉的仅仅代表作者的一家之言，读者朋友姑妄听之，仅作参考。 阅读全文

摘要： 综上所述，要真正实现.NET 的跨平台伟业，主要需要解决两个问题，一是针对不同的平台设计相应的运行时为中间语言CIL提供一个一致性的执行环境，而是提供统一的BCL以彻底解决代码复用的难题。对于真正跨平台的.NET Core来说，微软不仅为它设计了针对不同平台被成为CoreCLR的运行时，同时还重新设计了一套被称为CoreFX的BCL。 阅读全文

摘要： 在《.NET Core跨平台的奥秘[上篇]：历史的枷锁》中我们谈到：由于.NET是建立在CLI这一标准的规范之上，所以它天生就具有了“跨平台”的基因。在微软发布了第一个针对桌面和服务器平台的.NET Framework之后，它开始 “乐此不疲” 地对这个完整版的.NET Framework进行不同范围和层次的 “阉割” ，进而造就了像Windows Phone、Windows Store、Silverlight和.NET Micro Framework的压缩版的.NET Framework。从这个意义上讲，Mono和它们并没有本质的区别，唯一不同的是Mono真正突破了Windows平台的藩篱。包括Mono在内的这些分支促成了.NET的繁荣，但我们都知道这仅仅是一种虚假的繁荣而已。虽然都是.NET Framework的子集，但是由于它们采用完全独立的运行时和基础类库，这使我们很难开发一个支持多种设备的 阅读全文

摘要： 微软推出的第一个版本的.NET Framework是一个面向Windows桌面和服务器的基础框架，在此之后，为此微软根据设备自身的需求对.NET Framework进行裁剪，不断推出了针对具体设备类型的.NET Framework版本以实现针对移动、平板和嵌入式设备提供支持。除此之外，在Windows平台之外一致游荡着一只特立独行的猴子（Mono）。.NET平台看起来欣欣向荣，而实际上却日薄西山，就在这个时候微软走了一条唯一正确的道路，那就是基于跨平台理念重新设计的.NET Core，以及由此驱动地对整个.NET平台进行全新布局。 阅读全文

摘要： 对于一个 .NET开发人员，你可能没有使用过Docker，但是你不可能没有听说过Docker。Docker是Github上最受欢迎的开源项目之一，它号称要成为所有云应用的基石，并把互联网升级到下一代。Docker是dotCloud公司开源的一款产品，Docker从其诞生到现在，短短两三年的时间里已经成为了开源社区最火爆的项目。对于完全拥抱开源的.NET Core来说，它自然应该对Docker提供完美的支持。对于接下来的内容，我们假设你已经对Docker有了基本的了解，并且在你的机器上已经安装了Docker。 阅读全文

摘要： 如果想体验Linux环境下开发和运行.NET Core应用，我们有多种选择。一种就是在一台物理机上安装原生的Linux，我们可以根据自身的喜好选择某种Linux Distribution，目前来说像RHEL、Ubuntu、Debian、Fedora、CentOS和SUSE这些主流的Distribution都是支持的。如果读者朋友们觉得这种方式比较麻烦，我们也可以采用虚拟机的形式安装相应的Linux Distribution，比如我经常使用的都是安装在VirtualBox上的Ubuntu。对于64为Windows 10的用户来说，我们有了第三种选择，那就是Windows 10提供的Linux子系统（WSL： Windows Subsystem for Linux），接下来我们就来演示在WSL上运行.NET Core应用。 阅读全文

摘要： 除了微软自家的Windows平台， .NET Core针对Mac OS以及各种Linux（RHEL、Ubuntu、Debian、Fedora、CentOS和SUSE等）都提供了很好的支持，我们先来体验一下使用Mac来开发.NET Core应用，在这之前我们照例先得构建我们的开发环境。 阅读全文

摘要： 微软在千禧年推出 .NET战略，并在两年后推出第一个版本的.NET Framework和IDE（Visual Studio.NET 2002，后来改名为Visual Studio），如果你是一个资深的.NET程序员，相信传统的.NET应用的开发方式已经深深地烙印在你的脑子里面。.NET Core打来了全新的开发体验，但是开发方式的差异根本不足以成为你快速跨入.NET Core 世界的门槛，因为在.NET Core在很多方面比传统的.NET Framework应用开发要简单。为了消除很多尚未接触过.NET Core的读者对未知世界的恐惧，我们先通过几个简单的Hello World应用让大家感受一下.NET Core全新的开发体验。 阅读全文

摘要： 多年从事框架设计开发使我有了一种强迫症，那就是见不得一个应用里频繁地出现重复的代码。之前经常Review别人的代码，一看到这样的程序，我就会想如何将这些重复的代码写在一个地方，然后采用“注入”的方式将它们放到需要的程序中。我们知道AOP是解决这类问题最理想的方案。为此，我自己写了一个AOP框架，该框架被命名为Dora.Interception。Dora.Interception已经在GitHub上开源，如果有兴趣的朋友想下载源代码或者阅读相关文档，可以访问GitHub地址： 阅读全文

摘要： .NET Core针对缓存提供了很好的支持 ，我们不仅可以选择将数据缓存在应用进程自身的内存中，还可以采用分布式的形式将缓存数据存储在一个“中心数据库”中。对于分布式缓存，.NET Core提供了针对Redis和SQL Server的原生支持。除了这个独立的缓存系统之外，ASP.NET Core还借助一个中间件实现了“响应缓存”，它会按照HTTP缓存规范对整个响应实施缓存。不过按照惯例，在对缓存进行系统介绍之前，我们还是先通过一些简单的实例演示感知一下如果在一个ASP.NET Core应用中如何使用缓存。 阅读全文

摘要： StatusCodePagesMiddleware中间件与ExceptionHandlerMiddleware中间件比较类似，它们都是在后续请求处理过程中“出错”的情况下利用一个错误处理器来完成最终的请求处理与响应的任务。它们之间的差异在于对“错误”的界定上，对于ExceptionHandlerMiddleware中间件来说，它所谓的错误就是抛出异常，但是对于StatusCodePagesMiddleware中间件来说，则将介于400~599之间的响应状态码视为错误。 阅读全文

摘要： 我们知道整个ASP.NET Core建立在以ServiceCollection/ServiceProvider为核心的DI框架上，它甚至提供了扩展点使我们可以与第三方DI框架进行整合。对此比较了解的读者朋友应该很清楚，针对第三方DI框架的整合可以通过在定义Startup类型的ConfigureServices方法返回一个ServiceProvider来实现。但是真的有这么简单吗？ 阅读全文

摘要： DeveloperExceptionPageMiddleware中间件利用呈现出来的错误页面实现抛出异常和当前请求的详细信息以辅助开发人员更好地进行纠错诊断工作，而ExceptionHandlerMiddleware中间件则是面向最终用户的，我们可以利用它来显示一个友好的定制化的错误页面。 阅读全文

摘要： 在《ASP.NET Core应用的错误处理[1]：三种呈现错误页面的方式》中，我们通过几个简单的实例演示了如何呈现一个错误页面，这些错误页面的呈现分别由三个对应的中间件来完成，接下来我们将对这三个中间件进行详细介绍。在开发环境呈现的异常页面是通过一个类型为DeveloperExceptionPageMiddleware中间件实现的 阅读全文

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