摘要： 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通过怎样的方式来实现跨域资源共享呢？ 阅读全文

摘要： 在今天编辑推荐的《Hello Web API系列教程——Web API与国际化》，作者通过自定义的HttpMessageHandler的方式根据请求的Accep-Language报头设置当前线程UI Culture的方式来解决Localization的问题。如果你对ASP.NET Web API的执行机制有足够了解的话，你会发现实际上有很多种解决方案。不过这些解决方案都不够完美，原因很简单：ASP.NET Web API的整个框架均采用基于Task的并行编程模式，所以每个可扩展组件均可以在不同的线程中执行，这样会导致我们没有办法100%控制目标方法真正执行的线程的UI Culture。不过在默认情况下，大部分组件是按照同步的方式执行的，所以我们之需要在目标Action方法执行之前设置当前线程的UI Culture即可。 阅读全文

摘要： 我想大家还记得周星驰的《唐伯虎点秋香》中开篇的桥段：一群人一大早围在唐府门口，苦等两三个时辰，就为了求得一幅唐寅真迹。此时，唐府大门被打开，佣人出来倒垃圾，这群人蜂拥而至，为抢得唐寅墨宝而痛苦流涕。与此同时，唐府内一书童对正在烤鸡翅膀的唐寅说：“现在外头来了好多人来求画，真的不理他们？”，唐寅回答：“少爷今天没心情作画，拿几袋垃圾给他们先”。 阅读全文

摘要： Razor Engine，之前仅仅是ASP.NET MVC的一种View引擎，目前已经完全成为一种可以独立使用的模版引擎，并且已经成为了CodePlex上一个开源的项目（http://razorengine.codeplex.com/）。对于使用过ASP.NET MVC Razor视图引擎的朋友们一定已经领略过它的灵活性和易用性，在这篇文章中我们将利用它来实现一个代码生成器使我们可以以Razor的语法来定义代码模版。[源代码从这里下载] 阅读全文

摘要： ASP.NET Web API提供了一个独立于执行环境的抽象化的HTTP请求处理管道，而ASP.NET Web API自身的路由系统也不依赖于ASP.NET路由系统，所以它可以采用不同的寄宿方式运行于不同的应用程序中。如果采用Web Host的方式将定义Web API寄宿于一个Web应用之中，其实最终的URL路由还是通过ASP.NET本身的路由系统完成的，那么两个路由系统之间是如何衔接在一起的呢？。[本文已经同步到《How ASP.NET Web API Works?》] 阅读全文

摘要： 在未来的一段时间里，我将撰写一系列关于ASP.NET Web API的文章。这些文章旨在剖析ASP.NET Web API框架底层的运行机制，力求将整个框架这个黑盒转换为百盒，将框架本身进行请求处理的流程完整而清晰地呈现在读者面前，让读者知其然并知其所以然。 阅读全文

摘要： 虽然ASP.NET Web API框架采用与ASP.NET MVC框架类似的管道式设计，但是ASP.NET Web API管道的核心部分（定义在程序集System.Web.Http.dll中）已经移除了对System.Web.dll程序集的依赖，实现在ASP.NET Web API框架中的URL路由系统亦是如此。也就是说，ASP.NET Web API核心框架的URL路由系统与ASP.NET本身的路由系统是相对独立的。但是当我们采用基于Web Host的方式（定义在程序集System.Web.Http.WebHost.dll）将ASP.NET Web API承载于一个ASP.NET Web应用的时候，真正实现URL路由的依然是ASP.NET本身的路由系统，Web Host实际上在这种情况下起到了一个“适配”的作用，是两个相对独立的路由系统的“适配器”。我们先来讨论一下实现在ASP.NET Web AP 阅读全文

摘要： 在很多情况下我们具有这样的需求：为一组相关的操作创建一个执行上下文并提供一个共享的数据容器，而不是简单地定义一个全局变量，或者将数据通过参数传来传去。这样的上下文一般具有其生命周期，它们在目标操作开始执行的时候被激活，在执行完成之后被回收。该上下文一般不能跨越多个线程，以避免多个线程操作相同的数据容器造成数据的不一致。针对这个需求，我们写了一个非常简单的例子，有兴趣的朋友可以看看。 阅读全文

摘要： 昨天写了《yield在WCF中的错误使用——99%的开发人员都有可能犯的错误[上篇]》，引起了一些讨论。关于yield关键字这个语法糖背后的原理（C#编译器将它翻译成什么）其实挺简单，虽然有时候因为误用它会导致一些问题，但是它本无过错。接下来，我们通过这篇短文简单地谈谈我所理解的yield。 阅读全文

摘要： 对于返回类型为IEnumerable的方法来说，我们可以使用yield return的方式来输出返回集合的元素。但是如果我们不了解yield 关键字背后的实现机制，很有可能造成很大的问题。这是一个WCF相关的问题，我想99%的人都有可能会犯这样的错误——即使你对yield了解得非常透彻。 阅读全文

摘要： 对于企业开发来说，代码生成在某种意义上可以极大地提高开发效率和质量。在众多代码生成方案来说，T4是一个不错的选择，今天花了点时间写了一个简易版本的T4代码生成的“框架”，该框架仅仅是定义了一些基本的基类以及其他与VS集成相关功能的类型而已。[源代码从这里下载] 阅读全文

摘要： 对于面向数据的Web应用来说，MVVM模式是一项不错的选择，它借助JS框架提供的“绑定”机制是我们无需过多关注UI（HTML）的细节，只需要操作绑定的数据源。MVVM最早被微软应用于WPF/SL的开发，所以针对Web的MVVM框架来说，Knockout.js（以下简称KO）无疑是“根正苗红”。在进行基于KO的Web应用开发时，我们一般会为具体的Web页面定义针对性的ViewModel，但是在很多情况下很多页面具有相同的UI结构和操作行为，考虑到重用和封装，我们是否为它们创建一个共享的ViewModel呢。最近在一个小项目中，我们对这种方式进行了尝试，觉得是可行的，但同时也发现的一些问题。这篇文章通过一个简化的实例来讨论这种开发方式. 阅读全文

摘要： Ajax在Web应用中使用得越来越频繁。在进行Ajax调用过程中一般都具有这样的做法：显示一个GIF图片动画表明后台正在工作，同时阻止用户操作本页面（比如Ajax请求通过某个按钮触发，用户不能频繁点击该按钮产生多个并发Ajax请求）；调用完成后，图片消失，当前页面运行重新编辑 阅读全文

摘要： 在默认情况下，IE会针对请求地址缓存Ajax请求的结果。换句话说，在缓存过期之前，针对相同地址发起的多个Ajax请求，只有第一次会真正发送到服务端。在某些情况下，这种默认的缓存机制并不是我们希望的（比如获取实时数据），这篇文章就来简单地讨论这个问题，以及介绍几种解决方案。 阅读全文

摘要： 新作《ASP.NET MVC 4框架揭秘》于两日前分别在互动网和当当网预售，得到了广大网友，尤其是园子里面的兄弟们的热烈响应和积极支持，作为作者的我甚为感动。今天将两个试读章节发布出来，朋友们可以据此做一个评估，看看这本书的内容和写作方式是否适合自己。本书一共十章，整书近600页，书中给出了100来个演示实例，全部源代码均可单独下载。两个试读章节分别为第1章《ASP.NET + MVC》和第3章《Controller的激活》。 阅读全文

摘要： 本人历时近1年写的书《ASP.NET MVC 4框架揭秘》（电子工业出版社“博文视点”）于世界末日前得以出版，目前互动出版网已经开始接受预订。本书不是一本介绍ASP.NET MVC的入门书籍，它针对最新版本的ASP.NET MVC 4，深入剖析底层框架从请求接收到响应回复的整个处理流程（包括URL路由、Controller的激活、Model元数据的解析、Model的绑定、Model的验证、Action的执行、View的呈现和ASP.NET Web API等），并在此基础上指导读者如何通过对ASP.NET MVC框架本身的扩展解决应用开发中的实际问题。 阅读全文

摘要： 我们知道ASP.NET MVC默认集成了jQuery Validation，但是对于通过JavaScript动态添加的表单，客户端验证默认情况下是失效的。为了解决这个问题，可以在动态注入表单之后按照如下的方式调用$.validator.unobtrusive.parse()对表单元素进行重新解析。 阅读全文

摘要： 随着最终用户对用户体验需求的不断提高，实际上我们很多情况下已经在按照桌面应用的标准来设计Web应用，甚至很多Web页面本身就体现为一个单一的页面。对于这种复杂的页面，我们在设计的时候不可以真的将所有涉及的元素通通至于某个单独的View中，将复杂页面相对独立的内容“分而治之”才是设计之道。我们可以借鉴Smart Clent应用的设计方式：将一个Windows Form作为应用的容器（Smart Client Shell），在操作过程中动态地激活相应的用户控件（Smart Client Part）并加载到容器中。对于一个复杂页面来说，我们也只需要将其设计成一个容器，至于运行过程中动态显示的内容则可以通过Ajax调用获取相应的HTML来填充。 阅读全文