在《通过扩展让ASP.NET Web API支持W3C的CORS规范》中，我们通过自定义的HttpMessageHandler自行为ASP.NET Web API实现了针对CORS的支持，实际上ASP.NET Web API自身也是这么做的，该自定义HttpMessageHandler就是System.Web.Http.Cors.CorsMessageHandler。 1: public class CorsMessageHandler : DelegatingHandler 2: {
.NET Core具有一个承载（Hosting）系统，承载需要在后台长时间运行的服务，一个ASP.NET Core应用仅仅是该系统承载的一种服务而已。承载系统总是采用依赖注入的方式来消费它在服务承载过程所需的服务。对于承载系统来说，原始的服务注册总是体现为一个IServiceCollection集合，最终的依赖注入容器则体现为一个IServiceProvider对象，如果要将第三方依赖注入框架整合进来，就需要利用它们解决从IServiceCollection集合到IServiceProvider对象之间的适配问题。
上篇文章我给大家讲解了ASP.NET Core的概念及为什么使用它，接着带着你一步一步的配置了.NET Core的开发环境并创建了一个ASP.NET Core的mvc项目，同时又通过一个实战教你如何在页面显示一个Content的列表。不知道你有没有跟着敲下代码，千万不要做眼高手低的人哦。这篇文章我们就会设计一些复杂的概念了，因为要对ASP.NET Core的启动及运行原理、配置文件的加载过程进行分析，依赖注入，控制反转等概念的讲解等。俗话说，授人以鱼不如授人以渔，所以文章旨在带着大家分析源码，让大家能知其然更能知其所以然。为了偷懒，继续使用上篇文章的例子了！有兴趣的朋友可以加群637326624相互交流！
上篇文章我给大家讲解了ASP.NET Core的概念及为什么使用它，接着带着你一步一步的配置了.NET Core的开发环境并创建了一个ASP.NET Core的mvc项目，同时又通过一个实战教你如何在页面显示一个Content的列表。不知道你有没有跟着敲下代码，千万不要做眼高手低的人哦。这篇文章我们就会设计一些复杂的概念了，因为要对ASP.NET Core的启动及运行原理、配置文件的加载过程进行分析，依赖注入，控制反转等概念的讲解等。俗话说，授人以鱼不如授人以渔，所以文章旨在带着大家分析源码，让大家能知其然更能知其所以然。为了偷懒，继续使用上篇文章的例子了！有兴趣的朋友可以加群637326624相互交流！ 再次感谢张队的审稿！
注意：当启用编辑button时，点击编辑button后会使一整行都切换成文本框。为了是一行中的一部分是文本框，须要把以整行的全部列都转换成模板，然后删掉编辑模板中的代码。这样就能使你想编辑的列转换成文本框。
生命周期决定了IServiceProvider对象采用怎样的方式提供和释放服务实例。虽然不同版本的依赖注入框架针对服务实例的生命周期管理采用了不同的实现，但总的来说原理还是类似的。在我们提供的依赖注入框架Cat中，我们已经模拟了三种生命周期模式的实现原理，接下来我们结合“服务范围”的概念来对这个话题做进一步讲述。
在使用 Autofac 作为 IoC 容器，因为 Autofac 默认的创建时机是在主机运行时。而在此 Module 被 Load 时注入的对象的注入的时机，将会在单元测试 Fake 注入之后，这就意味着 Load 时注入的对象将会覆盖 Fake 的对象。可以通过调用 Autofac 的 PreserveExistingDefaults 方法解决覆盖的问题
一个ASP.NET Core应用被启动之后就具有了针对请求的处理能力，而这个能力是由管道赋予的，所以应用的启动同时意味着管道的成功构建。由于管道是由注册的服务器和若干中间件构成的，所以应用启动过程中一个核心的工作就是完成中间节的注册。由于依赖注入在ASP.NET Core应用这得到非常广泛的应用，框架绝大部分的工作都会分配给我们预先注册的服务，所以服务注册也是启动WebHost过程的另一项核心工作。这两项在启动过程中必须完成的核心工作通过一个名为Startup的对象来承载。 [本文已经同步到《ASP.NET
在ASP.NET Core中实现依赖注入的第一步是配置依赖注入。ASP.NET Core使用了一个称为依赖注入容器（DI Container）的组件来管理对象之间的依赖关系。DI容器在应用程序启动时被配置，并且可以在应用程序的整个生命周期内使用。以下是配置依赖注入的基本步骤：
前几天在webapi项目中遇到一个问题：Controller构造函数中抛出异常时全局过滤器捕获不到，于是网搜一把写下这篇博客作为总结。
在《配置模型总体设计》介绍配置模型核心对象的时候，我们刻意回避了与配置同步相关的API，现在我们利用一个独立文章来专门讨论这个话题。配置的同步涉及到两个方面：第一，对原始的配置源实施监控并在其发生变化之后重新加载配置；第二，配置重新加载之后及时通知应用程序进而使应用能够及时使用最新的配置。要了解配置同步机制的实现原理，我们先得了解一下配置数据的流向。
通过《利用容器提供服务》我们知道作为依赖注入容器的IServiceProvider对象是通过调用IServiceCollection接口的扩展方法BuildServiceProvider创建的，IServiceCollection对象是一个存放服务注册信息的集合。在《一个迷你版DI框架》中创建的Cat框架中的服务注册是通过类型ServiceRegistry表示的，在.NET Core依赖注入框架中，与之对应的类型是ServiceDescriptor。
在依赖注入（Dependency Injection，简称 DI）中，生命周期和作用域是非常重要的概念，它们对于正确设计和实现软件系统具有至关重要的作用。以下是生命周期和作用域在依赖注入中重要性的详细阐述：
ASP.NET Core请求处理管道由一个服务器和一组有序排列的中间件构成，所有中间件针对请求的处理都在通过HttpContext对象表示的上下文中进行。由于应用程序总是利用服务器来完成对请求的接收和响应工作，所以原始请求上下文的描述由注册的服务器类型来决定。但是ASP.NET Core需要在上层提供具有一致性的编程模型，所以我们需要一个抽象的、不依赖具体服务器类型的请求上下文描述，这就是本章着重介绍的HttpContext。[本文节选自《ASP.NET Core 3框架揭秘》第13章, 更多关于ASP.NET Core的文章请点这里]
和传统的分布式远程调用一样，WCF的服务调用借助于服务代理（Service Proxy）。而ChannelFactory<T>则是服务代理的创建者。WCF采用基于终结点（Endpoint）服务消费方式：WCF服务通过一个或者多个终结点暴露给潜在的服务消费者，服务的消费中通过与之匹配的终结点与之交互。在客户端，我们具有两种典型的服务代理创建方式，其一是通过诸如SvcUtil.exe这样的工具导入服务的元数据生成相应的服务代理（一个继承自ClientBase<T>的类型）代码和相关配置；其二是直接通过相应的终结
我们一致在说 ASP.NET Core广泛地使用到了依赖注入，通过前面两个系列的介绍，相信读者朋友已经体会到了这一点。由于前面两章已经涵盖了依赖注入在管道构建过程中以及管道在处理请求过程的应用，但是内容相对分散和零碎，我们有必要针对这个主题作一个归纳性的介绍。采用依赖注入的服务均由某个ServiceProvider来提供，但是在ASP.NET Core管道涉及到两个不同的ServiceProvider，其中一个是在管道成功构建后创建并绑定到WebHost上的ServiceProvider，对应着WebHos
Unity是微软P&P推出的一个开源的IoC框架，最新的官方版本是2.0。Unity之前的版本建立在一个称为ObjectBuild的组件上，熟悉EnterLib的读者，相信对ObjectBuild不会感到陌生。对于EnterLib 5.0之前的版本，ObjectBuild可以说是所有Application Block的基石。ObjectBuild提供一种扩展、可定制的对象创建方式，虽然微软官方没有将ObjectBuild和IoC联系在一起，其本质可以看成是一个IoC框架。在Unity 2.0中，微软直接将O
作为Controller基类ControllerBase的Execute方法的核心在于对Action方法的执行和作为方法返回的ActionResult的执行，两者的执行是通过一个叫做ActionInvoker的组件来完成的。 一、ActionInvoker 我们同样为ActionInvoker定义了一个接口IActionInvoker。如下面的代码片断所示，该接口定义了一个唯一的方法InvokeAction用于执行指定名称的Action方法，该方法的第一个参数是一个表示基于当前Controller上下文的C
我们知道ASP.NET Core请求处理管道由一个服务器和一组有序的中间件组成，所以从总体设计来讲是非常简单的，但是就具体的实现来说，由于其中涉及很多对象的交互，我想很少人能够地把它弄清楚。为了让读者朋友们能够更加容易地理解管道处理HTTP请求的总体流程，我们根据真实管道的实现原理再造了一个“模拟管道”并在此管道上开发了一个发布图片的应用，这篇文章旨在为你讲述管道是如何处理HTTP请求的 目录 一、HttpApplication FeatureCollection HostingAppli
开篇：上一篇我们了解了一个请求从客户端发出到服务端接收并转到ASP.Net处理入口的过程，这篇我们开始探索ASP.Net的核心处理部分，借助强大的反编译工具，我们会看到几个熟悉又陌生的名词（类）：HttpRuntime、HttpWorkerRequest、HttpContext、HttpApplication等。
POI（Point Of Interest），感兴趣点，其实呢，严格意义上说应该不是POI，但是单位就这样叫了，我也就这样叫了，其实现的功能大致是这样的：用过百度地图的朋友们都知道你在百度地图时，当鼠标经过某个点时会显示这个对象的名称，点击该对象，会弹出该对象的详细信息。如下图所示：
通过第一天的学习之后,我们相信您已经对MVC有一些基本了解。 本节所讲的内容是在上节的基础之上，因此需要确保您是否掌握了上一节的内容。本章的目标是在今天学习结束时利用最佳实践解决方案创建一个小型的MV
注册的服务器和中间件共同构成了ASP.NET Core用于处理请求的管道， 这样一个管道是在我们启动作为应用宿主的WebHost时构建出来的。要深刻了解这个管道是如何被构建出来的，我们就必须对WebHost和它的创建者WebHostBuilder这个重要的对象具有深刻的理解。[本文已经同步到《ASP.NET Core框架揭秘》之中] 目录 一、WebHost WebHostOptions 构建管道的三个步骤 二、WebHostBuilder WebHost的创建 几个常用的
当我们最开始学习一门技术的时候都喜欢从Hello World来时，貌似和我们本篇的主题不太搭。但事实却非如此，在我们看来如下这个Hello World是对ASP.NET Core框架本质最好的体现。
经过WCF基础的ABC学习，已经可以构建简单的WCF的服务，使用不同的服务地址和绑定类型，根据业务提供所需的服务契约。但不禁想问，服务所使用的消息报文是什么样的形式么？蕴含什么样内容呢？WCF服务是否
包含服务注册信息的IServiceCollection集合最终被用来创建作为依赖注入容器的IServiceProvider对象。当需要消费某个服务实例的时候，我们只需要指定服务类型调用IServiceProvider的GetService方法即可，IServiceProvider对象就会根据对应的服务注册提供所需的服务实例。
针对终结点的路由是由EndpointRoutingMiddleware和EndpointMiddleware这两个中间件协同完成的。应用在启动之前会注册若干表示终结点的Endpoint对象（具体来说是包含路由模式的RouteEndpoint对象）。如下图所示，当应用接收到请求并创建HttpContext上下文之后，EndpointRoutingMiddleware中间件会根据请求的URL及其他相关信息从注册的终结点中选择匹配度最高的那个。之后被选择的终结点会以一个特性（Feature）的形式附加到当前HttpContext上下文中，EndpointMiddleware中间件最终提供这个终结点并用它来处理当前请求。[更多关于ASP.NET Core的文章请点这里]
在一个ASP.NET MVC应用来说，针对HTTP请求的处理和相应定义Controller类型的某个Action方法中，每个HTTP请求的目标对象不再像ASP .NET Web Form应用一样是一个物理文件，而是某个Controller的某个Action。目标Controller和Action的名称包含在HTTP请求中，而ASP.NET MVC的首要任务就是通过当前HTTP请求的解析得到正确的Controller和Action的名称。这个过程是通过ASP.NET MVC的URL路由机制来实现的。 一、Ro
提到“配置”二字，我想绝大部分.NET开发人员脑海中会立即浮现出两个特殊文件的身影，那就是我们再熟悉不过的app.config和web.config，多年以来我们已经习惯了将结构化的配置定义在这两个XML格式的文件之中。到了.NET Core的时代，很多我们习以为常的东西都发生了改变，其中就包括定义配置的方式。总的来说，新的配置系统显得更加轻量级，并且具有更好的扩展性，其最大的特点就是支持多样化的数据源。我们可以采用内存的变量作为配置的数据源，也可以将配置定义在持久化的文件甚至数据库中。在对配置系统进行系统介绍之前，我们先从编程的角度来体验一下全新的配置读取方式。
在采用了依赖注入的应用中，我们总是直接利用DI容器直接获取所需的服务实例，换句话说，DI容器起到了一个服务提供者的角色，它能够根据我们提供的服务描述信息提供一个可用的服务对象。ASP.NET Core中的DI容器体现为一个实现了IServiceProvider接口的对象。 ServiceProvider与ServiceDescriptor 服务的注册与提供 利用ServiceProvider来提供服务 提供一个服务实例的集合 获取ServiceProvider自身对象 对
个人觉得异常处理对于程序员来说是最为熟悉的同时也是最难掌握的。说它熟悉，因为仅仅就是try/catch/finally而已。说它难以掌握，则是因为很多开发人员却说不清楚try/catch/finally应该置于何处？什么情况下需要对异常进行日志记录？什么情况下需要对异常进行封装？什么情况下需要对异常进行替换？对于捕获的异常，在什么情况下需要将其再次抛出？什么情况下则不需要？ 合理的异常处理应该是场景驱动的，在不同的场景下，采用的异常处理策略往往是不同的。异常处理的策略应该是可配置的，因为应用程序出现怎样的异
在很多大团队开发的时候，将需要用到很多项目的组合开发一个软件，一个软件需要用到的项目有很多个，很少会用到一个项目就能做到。但多个项目一起开发，在配置管理和团队管理有不同的策略，一个就是让项目拆分为多个代码仓库，另一个就是将这些项目合在一个代码仓库。两个策略不能说哪个更好，本文和大家分享我所在的团队和我参与的其他团队的策略
从上面的内容我们知道ASP.NET Core请求处理管道由一个服务器和一组中间件构成，所以从总体设计来讲是非常简单的。但是就具体的实现来说，由于其中涉及很多对象的交互，很少人能够地把它弄清楚。如果想非常深刻地认识ASP.NET Core的请求处理管道，我觉得可以分两个步骤来进行：首先，我们可以在忽略具体细节的前提下搞清楚管道处理HTTP请求的总体流程；在对总体流程有了大致了解之后，我们再来补充这些刻意忽略的细节。为了让读者朋友们能够更加容易地理解管道处理HTTP请求的总体流程，我们根据真实管道的实现原理再造
这样做的好处是可以在使用时决定具体的实现，也就意味着未来可以做任意的扩展，替换依赖注入框架的具体实现
基于IHostBuilder/IHost的服务承载系统建立在依赖注入框架之上，它在服务承载过程中依赖的服务（包括作为宿主的IHost对象）都由代表依赖注入容器的IServiceProvider对象提供。在定义承载服务时，也可以采用依赖注入方式来消费它所依赖的服务。作为依赖注入容器的IServiceProvider对象能否提供我们需要的服务实例，取决于相应的服务注册是否预先添加到依赖注入框架中。服务注册可以通过调用IHostBuilder接口或者IWebHostBuilder接口相应的方法来完成，前者在《服务承载系统》已经有详细介绍，下面介绍基于IWebHostBuilder接口的服务注册。[本文节选自《ASP.NET Core 3框架揭秘》第11章, 更多关于ASP.NET Core的文章请点这里]
ASP.NET Core的核心是通过一个Server和若干注册的Middleware构成的管道，不论是管道自身的构建，还是Server和Middleware自身的实现，以及构建在这个管道的应用，都需要相应的服务提供支持，ASP.NET Core自身提供了一个DI容器来实现针对服务的注册和消费。换句话说，不只是ASP.NET Core底层框架使用的服务是由这个DI容器来注册和提供，应用级别的服务的注册和提供也需要以来这个DI容器，所以正如本文标题所说的——学习ASP.NET Core，你必须了解无处不在的“依
ASP.NET Core应用本质上就是一个由中间件构成的管道，承载系统将应用承载于一个托管进程中运行起来，其核心任务就是将这个管道构建起来。从设计模式的角度来讲，“管道”是构建者（Builder）模式最典型的应用场景，所以ASP.NET Core先后采用的三种承载方式都是采用这种模式。(本篇提供的实例已经汇总到《ASP.NET Core 6框架揭秘-实例演示版》）
一、此文是Code Project社区2010年4月ASP.NET板块的最佳文章，说明了此文的份量；
构成ASP.NET Web API核心框架的消息处理管道既不关心请求消息来源于何处，也不需要考虑响应消息归于何方。当我们采用Web Host模式将一个ASP.NET应用作为目标Web API的宿主时，实际上是由ASP.NET管道解决了这两个问题。具体来说，ASP.NET自身的URL路由系统借助于HttpControllerHandler这个自定义的HttpHandler实现了ASP.NET管道和ASP.NET Web API管道之间的“连通”，但是在Self Host寄宿模式下，请求的监听、接收和响应又是如
理解 dotNET Core 中的管道模型，对我们学习 dotNET Core 有很大的好处，能让我们知其然，也知其所以然，这样在使用第三方组件或者自己写一些扩展时，可以避免入坑，或者说避免同样的问题多次入坑。
在编程的世界里，设计模式是为了解决反复出现的问题而总结出的优秀解决方案。它们帮助我们组织代码，使其更加清晰、可维护和可重用。然而，并非所有情境都需要应用设计模式。特别是当面对简单情境时，过度设计可能会带来不必要的复杂度。在本文中，我们将探讨在只需创建单一类型对象时，设计模式的必要性。
ASP.NET Core框架建立在一些核心的基础框架之上，这些基础框架包括依赖注入、文件系统、配置选项和诊断日志等。这些框架不仅仅是支撑ASP.NET Core框架的基础，我们在进行应用开发的时候同样会频繁地使用到它们。对于这里提到的这几个基础框架，依赖注入尤为重要。ASP.NET Core应用在启动以及后续针对请求的处理过程中，它会依赖各种的组件提供服务。为了便于定制，这些组件一般会以接口的形式进行“标准化”，我们将这些标准化的组件统一称为“服务（Service）”。整个ASP.NET Core框架建立在一个底层的依赖注入框架之上，它使用依赖注入容器来提供所需的服务对象。要了解这个依赖注入容器以及它的服务提供机制，我们得先知道什么是“依赖注入（DI：Dependence Injection）”。一旦我们提到依赖注入，又不得不说说“控制反转（IoC：Inverse of Control）”。
到目前为止，ASP.NET Core提供了两种不同的路由解决方案。传统的路由系统以IRouter对象为核心，我们姑且将其称为IRouter路由。本章介绍的是最早发布于ASP.NET Core 2.2中的新路由系统，由于它采用基于终结点映射的策略，所以我们将其称为终结点路由。终结点路由自然以终结点为核心，所以先介绍终结点在路由系统中的表现形式。[更多关于ASP.NET Core的文章请点这里]
YOYOFx是一个轻量级用于构建基于 HTTP 的 Web 服务，基于 .NET 和 Mono 平台。
在《管道是如何处理HTTP请求的？》中，我们对ASP.NET Core的请求处理管道的构成以及它对请求的处理流程进行了详细介绍，接下来我们需要了解的是这样一个管道是如何被构建起来的。这样一个管道由一个服务器和一个HttpApplication构成，前者负责监听请求并将接收的请求传递给给HttpAppkication对象处理，后者则将请求处理任务委托给注册的中间件来完成。中间件的注册是通过ApplicationBuilder对象来完成的，所以我们先来了解一下这究竟是个怎样的对象。 目录 Applicati
应用程序设计和架构优化是提高 ASP.NET Core 应用程序性能的重要方面之一。适当的设计模式是优化架构的关键之一。设计模式是解决特定问题的经验总结，能够提高代码的可读性、可维护性和可扩展性，从而间接地提高了性能。下面是一些在 ASP.NET Core 中常用的设计模式：
和mysql 注入有些不同，union select 无法使用，Sql Server数据库只能用 union all
foreach( object o in array )arrayList.Add(o);
Web API调用请求的目标是定义在某个HttpController类型中的某个Action方法，所以消息处理管道最终需要激活目标HttpController对象。调用请求的URI会携带目标HttpController的名称，该名称经过路由解析之后会作为路由变量保存到一个HttpRouteData对象中，而后者会被添加到代表当前请求的HttpRequestMessage对象的属性字典中。ASP.NET Web API据此解析出目标HttpController的类型，进而实现针对目标HttpControlle
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
即时通信 IM
实时音视频
