摘要： 较之传统通过App.config和Web.config这两个XML文件承载的配置系统，ASP.NET Core采用的这个全新的配置模型的最大一个优势就是针对多种不同配置源的支持。我们可以将内存变量、命令行参数、环境变量和物理文件作为原始配置数据的来源，如果采用物理文件作为配置源，我们可以选择不同的格式，比如XML、JSON和INI等。如果这些默认支持的配置源形式还不能满足你的需求，我们还可以通过注册自定义ConfigurationProvider的方式将其他形式数据作为我们的配置来源。接下来就让我们来逐个认识一下配置模型原生提供的ConfigurationProvider。 阅读全文

摘要： 我们在《读取配置信息》通过实例的形式演示了如何利用Options模型以依赖注入的方式直接获取由指定配置节绑定生成的Options对象，我们再次回顾一下当初我们编写的程序。如下面的代码片段所示，基于Options模型的配置绑定的编程基本采用这样的模式：先后调用ServiceCollection的扩展方法AddOption和Configure注册Options模型相关的服务并完成Options类型与指定配置节之间的映射，然后利用由此生成ServiceProvider获得一个类型为IOptions的服务示例，后者的Value就是配置绑定生成的Options对象。 阅读全文

摘要： 出于编程上的便利，我们通常不会直接利用ConfigurationBuilder创建的Configuration对象读取某个单一配置项的值，而是倾向于将一组相关的配置绑定为一个对象，我们将后者称为Options对象。我们在本章第一节通过简单的实例演示了如何利用Options模型实现了配置数据向Options对象的绑定，现在我们对Options模型背后的实现原理进行详细介绍。 阅读全文

摘要： 在上面一章我们以实例演示的方式介绍了几种读取配置的几种方式，其中涉及到三个重要的对象，它们分别是承载结构化配置信息的Configuration，提供原始配置源数据的ConfigurationProvider，以及作为“中间人”的ConfigurationBuilder。现在我们对 以这三个对象为核心的配置模型进行深入介绍。 阅读全文

摘要： 提到“配置”二字，我想绝大部分.NET开发人员脑海中会立马浮现出两个特殊文件的身影，那就是我们再熟悉不过的app.config和web.config，多年以来我们已经习惯了将结构化的配置信息定义在这两个文件之中。到了.NET Core的时候，很多我们习以为常的东西都发生了改变，其中也包括定义配置的方式。总的来说，新的配置系统显得更加轻量级，并且具有更好的扩展性，其最大的特点就是支持多样化的数据源。我们可以采用内存的变量作为配置的数据源，也可以直接配置定义在持久化的文件甚至数据库中。 阅读全文

摘要： 到目前为止，我们定义的ServiceProvider已经实现了基本的服务提供和回收功能，但是依然漏掉了一些必需的细节特性。这些特性包括如何针对IServiceProvider接口提供一个ServiceProvider对象，何创建ServiceScope，以及如何提供一个服务实例的集合。 阅读全文

摘要： 通过上一篇的介绍我们应该对实现在ServiceProvider的总体设计有了一个大致的了解，但是我们刻意回避一个重要的话题，即服务实例最终究竟是采用何种方式提供出来的。ServiceProvider最终采用何种方式提供我们所需的服务实例取决于最终选择了怎样的ServiceCallSite，而服务注册是采用的ServiceDescriptor有决定了ServiceCallSite类型的选择。我们将众多不同类型的ServiceCallSite大体分成两组，一组用来创建最终的服务实例，另一类则与生命周期的管理有关。 阅读全文

摘要： 本系列前面的文章我们主要以编程的角度对ASP.NET Core的依赖注入系统进行了详细的介绍，如果读者朋友们对这些内容具有深刻的理解，我相信你们已经可以正确是使用这些与依赖注入相关的API了。如果你还对这个依赖注入系统底层的实现原理具有好奇心，可以继续阅读这一节的内容。 阅读全文

摘要： ServiceProvider最终提供的服务实例都是根据对应的ServiceDescriptor创建的，对于一个具体的ServiceDescriptor对象来说，如果它的ImplementationInstance和ImplementationFactory属性均为Null，那么ServiceProvider最终会利用其ImplementationType属性返回的真实类型选择一个适合的构造函数来创建最终的服务实例。我们知道服务服务的真实类型可以定义了多个构造函数，那么ServiceProvider针对构造函数的选择会采用怎样的策略呢？ 阅读全文

摘要： 在采用了依赖注入的应用中，我们总是直接利用DI容器直接获取所需的服务实例，换句话说，DI容器起到了一个服务提供者的角色，它能够根据我们提供的服务描述信息提供一个可用的服务对象。ASP.NET Core中的DI容器体现为一个实现了IServiceProvider接口的对象。ASP.NET Core针对依赖注入的编程主要体现在两个方面：其一，创建一个ServiceCollection对象并将服务注册信息以ServiceDescriptor对象的形式添加其中；其二，针对ServiceCollection对象创建对应的ServiceProvider并利用它提供我们需要的服务实例。 阅读全文

摘要： IoC主要体现了这样一种设计思想：通过将一组通用流程的控制从应用转移到框架之中以实现对流程的复用，同时采用“好莱坞原则”是应用程序以被动的方式实现对流程的定制。我们可以采用若干设计模式以不同的方式实现IoC，比如我们在上面介绍的模板方法、工厂方法和抽象工厂，接下来我们介绍一种更为有价值的IoC模式，即依赖注入（DI：Dependency Injection，以下简称DI）。 阅读全文

摘要： ASP.NET Core在启动以及后续针对每个请求的处理过程中的各个环节都需要相应的组件提供相应的服务，为了方便对这些组件进行定制，ASP.NET通过定义接口的方式对它们进行了“标准化”，我们将这些标准化的组件称为服务，ASP.NET在内部专门维护了一个DI容器来提供所需的服务。要了解这个DI容器以及现实其中的服务提供机制，我们先得知道什么是DI（Dependence Injection），而一旦我们提到DI，又不得不说IoC（Inverse of Control）。 阅读全文

摘要： ReactJS学习日志 阅读全文

摘要： 这是昨天一个同事遇到的问题，我觉得这是一个蛮大的问题，而且应该不是ASP.NET MVC的设计者有意为之，换言之，这可能是ASP.NET MVC的一个大Bug。 阅读全文

摘要： 设置自定义的入口程序体现应用本身与应用托管之间的分离，它使我们可以创建独立于托管环境的应用，并根据需要寄宿于任何一个我们希望的宿主程序下，对于Web应用来说这一点尤为重要。对于之前的Web应用来说，IIS是它们唯一的宿主，但是ASP.NET 5应用却可以将我们指定的入口程序作为宿主。如果将应用寄宿于我们指定的宿主程序，这样的寄宿方式被称为Self-Host，接下来我们通过一个具体的例子来演示如何定义一个简单的ASP.NET MVC应用，并采用Self-Host的方式启动它。 阅读全文

摘要： 对于上面创建的这个Hello World应用来说，程序入口点由应用自身来提供，所以应用本身具有自我执行的能力。从应用托管（Host）的角度来讲，这样的应用同时负责对自身的托管。将应用与托管环境独立起来其实是更好的选择，因为这样可以使同一个应用运行于不同的环境中。接下来我们就来演示如何为应用指定入口程序来达到应用与应用托管的分离。 阅读全文

摘要： 微软在开发ASP.NET 5（当时被称为ASP.NET vNext）是采用的代号为Project K，所以运行时被称为KRuntime。KRuntime是一个SDK，它包含了编译和运行应用程序的所有资源。接下来我们通过三个Hello World实例来演示如何利用KRuntime让我们编写的应用运行起来。这三个实例如此的简单，以至于我们根本不需要利用IDE来编写。作为第一个Hello World应用，我们会编写一个包含入口点的程序，并通过执行KRuntime的K.cmd命令来启动它。 阅读全文

摘要： 上次针对《ASP.NET Web API 2框架揭秘》举办了一次评论赠书活动，很多人问我相同的活动要不要针对《ASP.NET MVC 5框架揭秘》再来一次，为此我向出版社要了10本，其中5本以评论博客的形式送出，另5本则以转发微博的形式送出. 阅读全文

摘要： 今天算是新作《ASP.NET MVC 5框架揭秘》正式上架销售的日子（目前本书在互动网已经到货），为了让更多适合的朋友们能够阅读此书，同时也避免让不适合的读者误买此书，特将此书的样章发布出来。 阅读全文

摘要： 本书以一个模拟ASP.NET MVC内部运行机制的“迷你版MVC框架”作为开篇，其目的在于将ASP.NET MVC真实架构的“全景”勾勒出来。接下来本书以请求消息在ASP.NET MVC框架内部的流向为主线将相关的知识点串连起来，力求将”黑盒式”的消息处理管道清晰透明地展示在读者面前。相信精读本书的读者一定能够将ASP.NET MVC从接收请求到响应回复的整个流程了然于胸，对包括路由、Controller的激活、Model元数据的解析、Action方法的选择与执行、参数的绑定与验证、过滤器的执行以及View的呈现等相关的机制具有深刻的理解。本书以实例演示的方式介绍了很多与ASP.NET MVC相关的最佳实践，同时还提供了一系列实用性的扩展，相信它们一定能够解决你在真实开发过程中遇到的很多问题。本书最后一章提供的案例不仅仅用于演示实践中的ASP.NET MVC，很多的架构设计方面的东西也包含其中。除此之 阅读全文

摘要： 在继《WCF全面解析》、《ASP.NET MVC 4框架揭秘》之后，我的另一本书《ASP.NET Web API 2框架揭秘》于本月正式出版，《ASP.NET MVC 5框架揭秘》也即将推出。这几本上算畅销的技术书籍的出版源于多年写博客的积累，所以离不开博客园这个平台和广大网友的支持。作为回馈，我也学学汤姆大叔来一个评论送书活动。 阅读全文

摘要： 《ASP.NET Web API 2框架揭秘》以实例演示的方式介绍了很多与ASP.NET Web API相关的最佳实践，同时还提供了一系列实用性的扩展。本书详细讲解了ASP.NET Web API从接收请求到响应回复的整个流程，包括路由、Http Controller的激活、Action方法的选择与执行、参数的绑定与验证、过滤器的执行和安全等相关的机制。 阅读全文

摘要： 本书以实例演示的方式介绍了很多与ASP.NET Web API相关的最佳实践，同时还提供了一系列实用性的扩展。本书详细讲解了ASP.NET Web API从接收请求到响应回复的整个流程，包括路由、Http Controller的激活、Action方法的选择与执行、参数的绑定与验证、过滤器的执行和安全等相关的机制。除此之外，本书在很多章节还从设计的角度对ASP.NET Web API的架构进行了深入分析，所以可以将本书当作一本架构设计的书来读。虽然与市面上任何一本相关的书相比，本书走得更远并更加近距离地触及到ASP.NET Web API框架的内核，但是就其内容本身来讲却没有涉及太多“高深莫测”的知识点，所以阅读本书不存在太高的门槛。如果你觉得自己对ASP.NET Web API所知甚少，可以利用此书来系统地学习ASP.NET Web API；如果你觉得自己对ASP.NET Web API足够精通，也一 阅读全文

摘要： 在《ASP.NET MVC下的四种验证编程方式》一文中我们介绍了ASP.NET MVC支持的四种服务端验证的编程方式（“手工验证”、“标注ValidationAttribute特性”、“让数据类型实现IValidatableObject或者IDataErrorInfo”），那么在ASP.NET MVC框架内部是如何提供针对这四种不同编程方式的支持的呢？接下来我们就来聊聊这背后的故事。 阅读全文

摘要： 由于频繁地使用反射会影响性能，所以ASP.NET MVC采用了表达式树的方式来执行目标Action方法。具体来说，ASP.NET MVC会构建一个表达式来体现针对目标Action方法的执行，并且将该表达式编译成可执行代码。编译后的可执行代码体现为一个委托对象，该委托对象会被缓存起来以用于针对同一个Action方法的执行。为了让大家能够和直观地理解两种（直接利用反射和利用表达式编译后的委托对象）方法执行在性能上的差异，我们来做一个简单的实例演示 阅读全文

摘要： 很多情况下目标Action方法都要求在一个安全上下文中被执行，这里所谓的安全上下文主要指的是当前请求者是一个经过授权的用户。授权的本质就是让用户在他许可的权限范围内做他能够做的事情，授权的前提是请求者是一个经过认证的用户。质询-应答（Chanllenge-Response）”是用户认证采用的一种常用的形式，认证方向被认证方发出质询以要求其提供用于实施认证的用户凭证，而被认证方提供相应的凭证以作为对质询的应答。旨在目标Action方法执行之前实施身分认证的AuthenticationFilter也对这种认证方法提供了支持。 阅读全文

摘要： 控制反转（Inversion of Control，IoC），简单地说，就是应用本身不负责依赖对象的创建和维护，而交给一个外部容器来负责。这样控制权就由应用转移到了外部IoC容器，控制权就实现了所谓的反转。比如在类型A中需要使用类型B的实例，而B实例的创建并不由A来负责，而是通过外部容器来创建。通过IoC的方式实现针对目标HttpController的激活具有重要的意义。 阅读全文

摘要： 通过《ASP.NET Web API的Controller是如何被创建的？》我们已经对HttpController激活系统的核心对象有了深刻的了解，在这篇文章中，对我们对此作一个总结。除此之外，本篇文章还会涉及一个大家极易忽视的问题——Controller是如何释放的？ 阅读全文

摘要： ASP.NET Web API在Self Host寄宿模式下用于解析程序集的AssembliesResolver是一个DefaultAssembliesResolver对象，它只会提供当前应用程序域已经加载的程序集。如果我们将HttpController定义在非寄宿程序所在的程序集中，即使我们将它们部属在宿主程序运行的目录中，宿主程序启动的时候也不会主动去加载这些程序集。由于当前应用程序域中并不曾加载这些程序集，HttpController类型解析将会失败，HttpController的激活自然就无法实现。 阅读全文

摘要： Web API调用请求的目标是定义在某个HttpController类型中的某个Action方法，所以消息处理管道最终需要激活目标HttpController对象。调用请求的URI会携带目标HttpController的名称，该名称经过路由解析之后会作为路由变量保存到一个HttpRouteData对象中，而后者会被添加到代表当前请求的HttpRequestMessage对象的属性字典中。ASP.NET Web API据此解析出目标HttpController的类型，进而实现针对目标HttpController实例的激活。 阅读全文

摘要： ASP.NET MVC采用Model绑定为目标Action生成了相应的参数列表，但是在真正执行目标Action方法之前，还需要对绑定的参数实施验证以确保其有效性，我们将针对参数的验证成为Model绑定。总地来说，我们可以采用4种不同的编程模式来进行针对绑定参数的验证。 阅读全文

摘要： 今天编写了一个采用ASP.NET Caching的组件，在为它编写Unit Test的过程中发现了一个有趣的问题... 阅读全文

摘要： 虽然通过Visual Studio向导在ASP.NET Web API项目中创建的 Controller类型默认派生与抽象类型ApiController，但是ASP.NET Web API框架本身只要求它实现IHttpController接口即可，所以我们将其统称为HttpController。 阅读全文

摘要： 构成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寄宿模式下，请求的监听、接收和响应又是如何实现的呢？ 阅读全文

摘要： 理想的RESTful Web API采用面向资源的架构，并使用请求的HTTP方法表示针对目标资源的操作类型。但是理想和现实是有距离的，虽然HTTP协议提供了一系列原生的HTTP方法，但是在具体的网络环境中，很多是不支持的。比如有的浏览器只能发送GET和POST请求，客户端发送的PUT请求也不一定能够被服务器理解。除了客户端和服务器对请求采用的HTTP方法的制约外，像代理（Proxy）、网管（Gateway）等这些中间部件都具有针对HTTP方法的限制。 阅读全文

摘要： ASP.NET Web API的核心框架是一个消息处理管道，这个管道是一组HttpMessageHandler的有序组合。这是一个双工管道，请求消息从一端流入并依次经过所有HttpMessageHandler的处理。在另一端，目标HttpController被激活，Action方法被执行，响应消息随之被生成。响应消息逆向流入此管道，同样会经过逐个HttpMessageHandler的处理。这是一个独立于寄宿环境的抽象管道，如何实现对请求的监听与接收，以及将接收的请求传入消息处理管道进行处理并将管道生成的响应通过网络回传给客户端，这就是Web API寄宿需要解决的问题。 阅读全文

摘要： Visual Studio为我们提供了专门用于创建ASP.NET Web API应用的项目模板，借助于此项目模板提供的向导，我们可以“一键式”创建一个完整的ASP.NET Web API项目。在项目创建过程中，VS会自动为我们添加必要的程序集引用和配置，甚至会为我们自动生成相关的代码。对于IDE提供的这种旨在提高生产效率的自动化机制，我个人自然是推崇的，但是我更推荐读者朋友们去了解一下这些自动化机制具体为我们做了什么？做这些的目的何在？哪些是必需的，哪些又是不必要的？正是基于这样的目的，在接下来演示的实例中，我们将摒弃VS为我们提供的向导，完全在创建的空项目中编写我们的程序。 阅读全文

摘要： 2000年，Roy Thomas Fielding博士在他那篇著名的博士论文《Architectural Styles and the Design of Network-based Software Architectures》中提出了一种软件应用的架构风格。REST是“REpresentational State Transfer”的缩写，可以翻译成“表现状态转换”。 阅读全文

摘要： REST不是一个标准，而是一种软件应用架构风格。基于SOAP的Web服务采用RPC架构，如果说RPC是一种面向操作的架构风格，而REST则是一种面向资源的架构风格。REST是目前业界更为推崇的构建新一代Web服务（或者Web API）的架构风格。由于REST仅仅是一种价格风格，所以它是与具体的技术平台无关的，也就是说采用REST架构的应用未必一定建立在Web之上，所以在正式介绍REST之前，我们先来简单认识一下Web。 阅读全文

摘要： 从安全的角度来讲，《中篇》介绍的Implicit类型的Authorization Grant存在这样的两个问题：其一，授权服务器没有对客户端应用进行认证，因为获取Access Token的请求只提供了客户端应用的ClientID而没有提供其ClientSecret；其二，Access Token是授权服务器单独颁发给客户端应用的，照理说对于其他人（包括拥有被访问资源的授权者）应该是不可见的。Authorization Code类型的Authorization Grant很好地解决了这两个问题。 阅读全文