[01] 技术剖析 - 随笔分类(第3页) - Artech

ASP.NET Core管道详解[3]: Pipeline = IServer + IHttpApplication

摘要：

ASP.NET Core的请求处理管道由一个服务器和一组中间件构成，但对于面向传输层的服务器来说，它其实没有中间件的概念。当服务器接收到请求之后，会将该请求分发给一个处理器进行处理，对服务器而言，这个处理器就是一个HTTP应用，此应用通过IHttpApplication接口来表示。由于服务器是通过IServer接口表示的，所以可以将ASP.NET Core框架的核心视为由IServer和IHttpApplication对象组成的管道阅读全文

posted @ 2020-11-24 09:14 Artech 阅读(2309) 评论(3) 推荐(8) 编辑

ASP.NET Core应用基本编程模式[5]：如何放置你的初始化代码

摘要：

一个ASP.NET Core应用的核心就是由一个服务器和一组有序中间件组成的请求处理管道，服务器只负责监听、接收和分发请求，以及最终完成对请求的响应，所以一个ASP.NET Core应用针对请求的处理能力和处理方式由注册的中间件来决定。一个ASP.NET Core在启动过程中的核心工作就是注册中间件，本节主要介绍应用启动过程中以中间件注册为核心的初始化工作。阅读全文

posted @ 2020-11-20 08:55 Artech 阅读(2201) 评论(0) 推荐(5) 编辑

ASP.NET Core应用基本编程模式[4]：基于承载环境的编程

摘要：

基于IHostBuilder/IHost的承载系统通过IHostEnvironment接口表示承载环境，我们利用它不仅可以得到当前部署环境的名称，还可以获知当前应用的名称和存放内容文件的根目录路径。对于一个Web应用来说，我们需要更多的承载环境信息，额外的信息定义在IWebHostEnvironment接口中。阅读全文

posted @ 2020-11-16 08:56 Artech 阅读(3422) 评论(1) 推荐(11) 编辑

ASP.NET Core应用基本编程模式[3]：配置多种使用形式

摘要：

IHostBuilder接口中定义了ConfigureHostConfiguration方法和ConfigureAppConfiguration方法，它们可以帮助我们设置面向宿主（IHost对象）和应用（承载服务）的配置。针对配置的初始化也可以借助IWebHostBuilder接口来完成。阅读全文

posted @ 2020-11-13 08:45 Artech 阅读(1415) 评论(1) 推荐(4) 编辑

ASP.NET Core应用基本编程模式[2]：依赖注入

摘要：

基于IHostBuilder/IHost的服务承载系统建立在依赖注入框架之上，它在服务承载过程中依赖的服务（包括作为宿主的IHost对象）都由代表依赖注入容器的IServiceProvider对象提供。在定义承载服务时，也可以采用依赖注入方式来消费它所依赖的服务。作为依赖注入容器的IServiceProvider对象能否提供我们需要的服务实例，取决于相应的服务注册是否预先添加到依赖注入框架中。阅读全文

posted @ 2020-11-12 08:46 Artech 阅读(3859) 评论(12) 推荐(11) 编辑

ASP.NET Core应用基本编程模式[1]：管道式的请求处理

摘要：

HTTP协议自身的特性决定了任何一个Web应用的工作模式都是监听、接收并处理HTTP请求，并且最终对请求予以响应。HTTP请求处理是管道式设计典型的应用场景：可以根据具体的需求构建一个管道，接收的HTTP请求像水一样流入这个管道，组成这个管道的各个环节依次对其做相应的处理。阅读全文

posted @ 2020-11-11 08:46 Artech 阅读(2915) 评论(3) 推荐(9) 编辑

ASP.NET Core框架揭秘[博文汇总-持续更新]

摘要：

第1部分跨平台开发体验 1 跨平台开发体验 001 跨平台开发体验: Windows [上篇] 002 跨平台开发体验: Windows [中篇] 003 跨平台开发体验: Windows [下篇] 004 跨平台开发体验: Mac OS 005 跨平台开发体验: Linux 006 跨平台开发体阅读全文

posted @ 2020-11-10 08:12 Artech 阅读(18854) 评论(21) 推荐(50) 编辑

怎样让1+1=3？

摘要：

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

posted @ 2019-08-14 20:43 Artech 阅读(5329) 评论(18) 推荐(26) 编辑

200行代码，7个对象——让你了解ASP.NET Core框架的本质

摘要：

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

posted @ 2019-01-28 08:09 Artech 阅读(52188) 评论(153) 推荐(360) 编辑

[文章汇总]ASP.NET Core框架揭秘[最近更新：2018/10/31]

摘要：

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

posted @ 2018-10-15 06:52 Artech 阅读(29925) 评论(54) 推荐(82) 编辑

依赖注入[8]: .NET Core DI框架[服务消费]

摘要：

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

posted @ 2018-08-03 06:10 Artech 阅读(6753) 评论(7) 推荐(22) 编辑

依赖注入[7]: .NET Core DI框架[服务注册]

摘要：

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

posted @ 2018-08-02 06:02 Artech 阅读(6286) 评论(6) 推荐(13) 编辑

依赖注入[6]: .NET Core DI框架[编程体验]

摘要：

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

posted @ 2018-08-01 06:18 Artech 阅读(11024) 评论(15) 推荐(19) 编辑

.NET Core跨平台的奥秘[下篇]：全新的布局

摘要：

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

posted @ 2017-11-10 08:07 Artech 阅读(36112) 评论(82) 推荐(147) 编辑

.NET Core跨平台的奥秘[中篇]：复用之殇

摘要：

在《.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的子集，但是由于它们采用完全独立的运行时和基础类库，这使我们很难开发一个支持多种设备的阅读全文

posted @ 2017-11-08 07:35 Artech 阅读(23379) 评论(33) 推荐(97) 编辑

.NET Core跨平台的奥秘[上篇]：历史的枷锁

摘要：

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

posted @ 2017-11-06 08:19 Artech 阅读(34407) 评论(42) 推荐(135) 编辑

ASP.NET Core应用的错误处理[4]：StatusCodePagesMiddleware中间件如何针对响应码呈现错误页面

摘要：

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

posted @ 2017-01-12 08:55 Artech 阅读(5413) 评论(9) 推荐(8) 编辑

ASP.NET Core应用的错误处理[3]：ExceptionHandlerMiddleware中间件如何呈现“定制化错误页面”

摘要：

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

posted @ 2017-01-06 08:28 Artech 阅读(9768) 评论(7) 推荐(10) 编辑

ASP.NET Core应用的错误处理[2]：DeveloperExceptionPageMiddleware中间件如何呈现“开发者异常页面”

摘要：

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

posted @ 2017-01-04 08:18 Artech 阅读(6176) 评论(5) 推荐(16) 编辑

ASP.NET Core应用的错误处理[1]：三种呈现错误页面的方式

摘要：

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

posted @ 2016-12-29 08:46 Artech 阅读(20406) 评论(6) 推荐(19) 编辑

随笔分类 - [01] 技术剖析

公告