摘要：在《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的过程中发现了一个有趣的问题... 阅读全文