摘要： 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很好地解决了这两个问题。 阅读全文

摘要： 虽然我们在《上篇》分别讨论了4种预定义的Authorization Grant类型以及它们各自的适用场景的获取Access Token的方式，我想很多之前没有接触过OAuth 2.0的读者朋友们依然会有“不值所云” 之感，所以在介绍的内容中，我们将采用实例演示的方式对Implicit和Authorization Code这两种常用的Authorization Grant作深入介绍。本章着重介绍Implicit Authorization Grant。 阅读全文

摘要： 在Internet环境下，我们针对具体的Web应用设计独立的认证系统往往是一件“吃力不讨好”的事情。如果我们开发一个很小的Web应用，可能在实现用户认证功能上面花费的成本比实现应用自身业务功能的成本更大，而且还会因为“信任危机”导致潜在的使用者不敢注册。 在这种情况下，如果一个值得信任的第三方能够提供一种免费的认证服务，那么这两个问题均会迎刃而解。实际上目前这样的第三方认证服务很多，而且他们的提供者均为值得信赖的IT服务提供商，比如微软、Google、Facebook、Twitter，以及国内的新浪、腾讯、网易、人人和豆瓣等。就目前来说，这些第三方认证服务绝大部分均是基于OAuth 2.0设计的。 阅读全文

摘要： 同源策略（Same Origin Policy）的存在导致了“源”自A的脚本只能操作“同源”页面的DOM，“跨源”操作来源于B的页面将会被拒绝。同源策略以及跨域资源共享在大部分情况下针对的是Ajax请求。同源策略主要限制了通过XMLHttpRequest实现的Ajax请求，如果请求的是一个“异源”地址，浏览器将不允许读取返回的内容。JSONP和CORS是两种常用的解决方案，本系列文章主要针对两者在ASP.NET Web API的应用展开讨论。 阅读全文

摘要： 在《通过扩展让ASP.NET Web API支持W3C的CORS规范》中，我们通过自定义的HttpMessageHandler自行为ASP.NET Web API实现了针对CORS的支持，实际上ASP.NET Web API自身也是这么做的，该自定义HttpMessageHandler就是System.Web.Http.Cors.CorsMessageHandler。 阅读全文

摘要： 通过《EnableCorsAttribute特性背后的故事》我们知道：由CorsPolicyProvider提供的CorsPolicy表示目标Action采用的资源授权策略，ASP.NET Web API最终需要利用它对具体的跨域资源请求实施授权检验并生成相应的CORS响应报头，而这是通过ASP.NET自身提供的CORS引擎来完成的。 阅读全文

摘要： 从编程的角度来讲，ASP.NET Web API针对CORS的实现仅仅涉及到HttpConfiguration的扩展方法EnableCors和EnableCorsAttribute特性。但是整个CORS体系不限于此，在它们背后隐藏着一系列的类型，我们将会利用本章余下的内容对此作全面讲述，今天我们就来讨论一下用于定义CORS授权策略的EnableCorsAttribute特性背后的故事。 阅读全文

摘要： 在《通过扩展让ASP.NET Web API支持W3C的CORS规范》中我们通过自定义的HttpMessageHandler为ASP.NET Web API赋予了跨域资源共享的能力，实际上ASP.NET Web API本身就提供了针对CORS的支持，就其实现原理来看，与我们的实现没有本质的区别。接下来我们通过实例演示如何利用ASP.NET Web API自身的支持来实现“跨域资源共享”。 阅读全文

摘要： 让ASP.NET Web API支持JSONP和W3C的CORS规范是解决“跨域资源共享”的两种途径，在《通过扩展让ASP.NET Web API支持JSONP》中我们实现了前者，并且在《W3C的CORS Specification》一文中我们对W3C的CORS规范进行了详细介绍，现在我们通过一个具体的实例来演示如何利用ASP.NET Web API具有的扩展点来实现针对CORS的支持。 阅读全文

摘要： 同源策略主要限制了通过XMLHttpRequest实现的Ajax请求，如果请求的是一个“异源”地址，浏览器将不允许读取返回的内容。JSONP是一种常用的解决跨域资源共享的解决方案，现在我们利用ASP.NET Web API自身的扩展性提供一种“通用”的JSONP实现方案。 阅读全文

摘要： 随着Web开放的程度越来越高，通过浏览器跨域获取资源的需求已经变得非常普遍。在我看来，如果Web API不能针对浏览器提供跨域资源共享的能力，它甚至就不应该被称为Web API。从另一方面来看，浏览器作为进入Internet最大的入口，是各大IT公司的必争之地，所以浏览器市场出现了种类繁多、鱼龙混杂的局面。针对这两点，我们迫切需要一种能够被各个浏览器厂商共同遵循的标准来对跨域资源共享作出规范，这就是由W3C指定2的CORS（Cross-Origin Resource Sharing）规范 阅读全文

摘要： Web API普遍采用面向资源的REST架构，将浏览器最终执行上下文的JavaScript应用Web API消费者的重要组成部分。“同源策略”限制了JavaScript的跨站点调用，这必然导致Web API不能垮域提供资源。如果Web API仅限于为“同源客户端”提供资源，那么它都对不起自己的名字，因为Web本身是一个开放的协议。那么ASP.NET Web API通过怎样的方式来实现跨域资源共享呢？ 阅读全文