摘要： 除了通过自定义ControllerFactory的方式引入IoC之外，在使用默认DefaultControllerFactory情况下也可以通过一些扩展使基于IoC的Controller激活成为可能。主要的方式就是自定义ControllerActivator和 DependencyResolver。 阅读全文

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

摘要： Controller激活系统最终通过注册的ControllerFactory创建相应的Conroller对象，如果没有对ControllerFactory类型或者类型进行显式注册（通过调用当前ControllerBuilder的SetControllerFactory方法），默认使用的是一个DefaultControllerFactory对象，我们现在就来讨论实现在DefaultControllerFactory类型中的默认Controller激活机制。 阅读全文

摘要： 我们将整个ASP.NET MVC框架划分为若干个子系统，那么针对请求上下文激活目标Controller对象的子系统被我们成为Controller激活系统。本系列将对Controller的激活系统进行深入地剖析，让你明白Controller到底是如何创建的。 阅读全文

摘要： 我们知道一个请求最终通过一个具体的HttpHandler进行处理，而我们熟悉的用于表示一个Web页面的Page对象就是一个HttpHandler，被用于处理基于某个.aspx文件的请求。我们可以通过HttpHandler的动态映射来实现请求地址与物理文件路径之间的分离。实际上ASP.NET路由系统就是采用了这样的实现原理。 阅读全文

摘要： ASP.NET 路由系统通过注册的路由表旨在实现两个“方向”的路有功能，即针对入栈请求的路由和出栈URL的生成。前者通过调用代表全局路由表的RouteCollection对象的GetRouteData方法实现，后者则依赖于RouteCollection的GetVirtualPathData方法，而最终还是落在继承自RouteBase的路由对象的同名方法的调用上。为了编程的方面，ASP.NET MVC为了设计了HtmlHelper和UrlHelper这两个帮助类，我们可以通过调用它们的ActionLink/RouteLink和Action/RouteUrl根据注册的路有规则生成链接或者URL。从本质上讲，HtmlHelper/UrlHelper实现的对URL的生成最终还是依赖于上面所说的GetVirtualPathData方法。 阅读全文

摘要： 上周我写了三篇文章（一、二、三）详细地介绍了ASP.NET的路由系统。ASP.NET的路由系统旨在通过注册URL模板与物理文件之间的映射进而实现请求地址与文件路径之间的分离，但是对于ASP.NET MVC应用来说，请求的目标不再是一个具体的物理文件，而是定义在某个Controller类型中的Action方法。出于自身路由特点的需要，ASP.NET对ASP.NET的路由系统进行了相应的扩展。 阅读全文

摘要： 前面我们已经提到过，ASP.NET 的路由系统主要具有两个方面的应用，其一就是通过注册URL模板与物理文件路径的匹配实现请求地址和物理地址的分离；另一个则是通过注册的路由规测生成一个相应的URL。后者通过调用RouteCollection类型的GetVirtualPath方法来实现。[源代码从这里下载] 阅读全文

摘要： 我们可以通过RouteTable的静态属性Routes得到一个基于应用的全局路由表，这是一个类型的RouteCollection的集合对象，我们可以通过调用它的MapPageRoute进行路由映射。接下来我们通过实现演示的方式来说明路由注册的一些细节问题。 阅读全文

摘要： 表现为请求地址与目标Controller和Action的动态映射的URL路由系统并不是专属于ASP.NET MVC，而是直接建立在ASP.NET 中。ASP.NET通过URL路由系统实现了请求地址与物理文件的分离。[源代码地址从这里下载] 阅读全文

摘要： 我们知道VS开发中引用的程序集和运行时的程序集来源于不同的地方，前者来源于%ProgramFiles%\Reference Assemblies\Microsoft\Framework\.NETFramework\v{version}，后者则来源于GAC，你是否发现了它们之间存在着差异吗？ 阅读全文

摘要： 在《为HtmlHelper添加一个RadioButtonList扩展方法》中我通过对HtmlHelper和HtmlHelper的扩展使我们可以采用”RadioButtonList”的方式对一组类型为“radio”的<input>元素进行操作。昨天对对此进行了一些改进，并将“CheckBoxList”的功能添加进来。[源代码从这里下载] 阅读全文

摘要： 在前面一篇文章中，我们通过对HtmlHelper的扩展简化了对DropDownList（Single-Line-Select）和ListBox（Multiple-Line-Select）的绑定，以及对作为数据源的列表进行单独维护。现在我们为HtmlHelper/HtmlHelper添加一个RadioButtonList/RadioButtonListFor扩展方法实现一组RadioButton的绑定。[源代码从这里下载] 阅读全文

摘要： 在众多表单元素中，有一类select元素用于绑定一组预定义列表。传统的ASP.NET Web Form中，它对应着一组重要的控件类型，即ListControl。ASP.NET MVC通过对HtmlHelper和HtmlHelper<TModel>的扩展实现了对不同类型的select元素的绑定，它们以扩展方法的形式定义在SelectExtensions中。当我们在操作这些扩展方法的时候，必须手工地提供列表项集合。如果我们建立一个独立的组件来维护这些预定的列表，那么我们就可以定义一些更加简单的扩展方法以避免手工地指定列表项。 阅读全文

摘要： 作为Controller基类ControllerBase的Execute方法的核心在于对Action方法的执行和作为方法返回的ActionResult的执行，两者的执行是通过一个叫做ActionInvoker的组件来完成的。由于Action方法具有相应的参数，在执行Action方法之前必须进行参数的绑定。ASP.NET MVC将这个机制成为Model的绑定，而这又涉及到另一个重要的组件ModelBinder 阅读全文

摘要： ASP.NET MVC的URL路由系统通过注册的路由表对HTTP请求进行解析从而得到一个用于封装路由数据的RouteData对象，而这个过程是通过自定义的UrlRoutingModule对HttpApplication的PostResolveRequestCache事件进行注册实现的。RouteData中已经包含了目标Controller的名称，现在我们来进一步分析真正的Controller对象是如何被激活的。 阅读全文

摘要： 在一个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路由机制来实现的。 阅读全文

摘要： ASP.NET由于采用了管道式设计，具有很好的扩展性，而整个ASP.NET MVC应用框架就是通过扩展ASP.NET实现的。通过上面对ASP.NET管道设计的介绍，我们知道ASP.NET的扩展点只要体现在HttpMoudle和HttpHandler这两个核心组建之上，实际上整个ASP.NET MVC框架就是通过自定义的HttpMoudle和HttpHandler实现的。为了上读者从整体上把握ASP.NET MVC的工作机制，接下来我按照其原理通过一些自定义组件来模拟ASP.NET MVC的运行原理，我们也可以将此视为一个“迷你版”的ASP.NET MVC。 阅读全文

摘要： 作为MVC最初提出者的Trygve M. H. Reenskau实际是将MVC视为一种范例（Paradigm）,模式和范例的区别在于前者可以直接应用到具体的应用上，而后者则仅仅提供一些基本的指导方针。在软件设计的发展历程中出现了一些MVC的变体（Varation），它们遵循定义在MVC中的基本原理。我们现在来简单地讨论一些一个常用的MVC变体。 阅读全文

摘要： MVC是Trygve M. H. Reenskau在1979年访问施乐帕克研究中心（Xerox PARC）期间是提出一种主要针对GUI应用的软件架构模式。MVC体现了关注点分离这一基本的设计方针，它将构成一个人机交互应用涉及到的功能分为Model、Controller和View三部分。本篇文章（上、下篇）为你详细介绍MVC模式和它两个常用的变体MVP和Model2。 阅读全文

摘要： 不知道大家是否意识到一个现象，我们所说的Web服务其实并没有直接建立在Web上而是建立在SOAP上。SOAP居然成为了Web服务的标准，以至于我们提到Web服务就会想到SOAP。随着在Web服务中引入了REST架构，SOAP在整个Web服务体系中的垄断地位正在发生改变，或者已经发生了改变。REST提倡一种面向资源的架构（ROA: Resource Oriented Architecture），鼓励我们直接在Web上建立一种轻量级的Web服务。WCF在3.5就提供了对REST的支持，在4.0中对此进行较大的改进。 阅读全文

摘要： 条件获取（Conditional Update）可以避免相同数据的重复传输，进而提高性能。条件更新（Conditional Update）用于解决资源并发操作问题。如果我们预先获取一个资源进行修改或者删除，条件更新检验帮助我们确认资源被获取出来到针对它的修改/删除操作被提交的这段时间内是否被其他人改动过。 阅读全文

摘要： 对于一个Numeric属性/字段，ASP.NET MVC会自动进行数据类型的验证（客户端验证），以确保输入的是一个有效的数字，但是呈现在页面上的错误消息总是一段固定的文本：“The field {0} must be a number”，本篇提供一种解决方案使我们可以对此验证消息进行定制。 阅读全文

摘要： 条件获取（Conditional Retrieval）旨在解决这样的问题：客户端获取某个资源并对其进行缓存，当再次获取相同资源时，如果资源数据与之前获取的一致，则不再返回真正的资源数据，而是在回复中设置一个“标识”表明获取的资源并未发生改变。 阅读全文

摘要： ASP.NET的输出缓存（Output Caching）机制允许我们针对整个Web页面或者页面的某个部分（主要针对用户控件）最终呈现的HTML进行缓存。对于后续针对相同资源的请求，只需要直接将缓存的HTML予以回复而无须按照页面处理生命周期对每次请求进行重复处理。WCF通过操作行为AspNetCacheProfileAttribute利用ASP.NET的输出缓存提供一种针对于某个操作的声明式缓存机制。 阅读全文

摘要： REST服务采用面向资源的架构，而资源通过URI进行标识和定位，所以URI在REST中具有重要的地位。对于WCF来说，服务调用请求的URI映射为某个具体的操作，所以服务端需要解决的是如何根据请求URI选择出对应的操作。如果采用SOAP，操作的选择是根据消息的报头来实现的，那么REST服务又采用怎样的操作选择机制呢？ 阅读全文

摘要： WCF为REST服务的寄宿提供了一个新的ServiceHost，即WebServiceHost。WebServiceHost是ServiceHost的子类，而WebServiceHostFactory是对应的ServiceHostFactory，在基于IIS/WAS寄宿中被使用。由于对REST服务绝大部分功能的支持都是通过WebHttpBehavior这么一个终结点行为实现的，所以WebServiceHost的核心功能就是将该终结点行为应用到寄宿服务的所有终结点。除此之外，WebServiceHost还具有一些额外的功能，这些功能都是通过重写OnOpening方法实现的。 阅读全文

摘要： 可以说WebHttpBinding和WebHttpBehavior是整个Web HTTP编程模型最为核心的两个类型，前者主要解决消息编码问题，而余下的工作基本上落在了终结点行为WebHttpBehavior上。WebHttpBehavior属性HelpEnabled和AutomaticFormatSelectionEnabled是“帮助页面”与“自动消息格式选择”这两个特性的总开关。 阅读全文

摘要： 我们知道请求消息和回复消息分别是对操作方法输入参数和返回值（输出参数和引用参数）的封装，而请求消息和回复消息的主体具有两种不同的风格，即Bare和Wrapped。的Bare表示请求消息和回复消息的主体部分仅仅包含针对输入参数和返回值（输出参数和引用参数）序列化后的内容，而Wrapped则会在外面包装一个基于当前操作的“封套”。 阅读全文

摘要： 不论是我们采用SOAP还是REST架构风格，运行时框架体系依然不曾改变，终结点也仍旧是通信的核心。在Web HTTP编程模型中，我们采用基于WebHttpBinding绑定的终结点。绑定是一组相关绑定元素的有序组合，绑定的特性与能力决定于它包含的绑定元素，在这里我们通过分析绑定元素的方式来剖析WebHttpBinding绑定与其它绑定有何不同 阅读全文

摘要： 微软在WCF 3.5中就通过提供基于Web HTTP的编程模式使我们很容易地创建基于REST的服务，WCF 4.0中对此进行了较大的改进。为了让读者对REST在WCF中的应用有一个大致的了解，我们先来进行一个简单的实例演示。 阅读全文

摘要： JSONP（JSON with Padding）可以看成是JSON的一种“使用模式”，用以解决“跨域访问”的问题，这篇简单的文章给出一个简单的例子用于模拟如何通过jQuery以JSONP的访问调用一个WCF REST服务。[源代码从这里下载] 阅读全文

摘要： 在《使用篇》中我们谈到扩展的验证编程方式，并且演示了本解决方案的三大特性：消息提供机制的分离、多语言的支持和多验证规则的支持，我们现在来看看这样的验证解决方案最终是如何实现的。 阅读全文

摘要： ASP.NET MVC采用DataAnnotations提供的元数据验证机制对Model实施验证，我们可以在Model类型或者字段/属性上应用相应的ValidationAttribute。但是在默认情况下，对于同一个类型的ValidationAttribute特性只允许一个应用到目标元素上——即使我们将AllowMultiple属性设置为True。这篇文章的目的就是为了解决这个问题。 阅读全文

摘要： 昨天我为了Attribute 的一个小问题后耗费了大半天的精力，虽然最终找到了问题的症结并解决了问题，但是我依然不知道微软如此设计的目的何在。闲话少说，我们先来演示一下我具体遇到的问题如何发生的。 阅读全文

摘要： ASP.NET MVC提供一种基于元数据的验证方式是我们可以将相应的验证特性应用到作为Model实体的类型或者属性/字段上，但是这依然具有很多的不足。在这篇文章中，我结合EntLib的VAB的一些思想通过扩展为ASP.NET MVC提供一种更为完善的验证机制。 阅读全文

摘要： EntLib的异常处理应用块（EHAB）是一个不错的异常处理框架，它使我们可以采用配置的方式来定义异常处理策略。而ASP.NET MVC是一个极具可扩展开发框架，在这篇文章中我将通过它的扩展实现与EntLib的集成，并提供一个完整的异常处理解决方案 阅读全文

摘要： System.Transactions.TransactionScope为了提供一种非常方便的实现分布式事务的方式，但是在某些情况下为了阻止本地事务向分布式事务提升，我们只能通过DbTransaction进行事务控制。在进行数据库操作的时候，我们经常会遇到这样的事务场景：当某个方法单独执行的时候，它应该在一个单一的DbTransaction中执行；当多个方法一起执行的时候，它们应用共同在DbTransaction中执行。在本篇文章中我们通过对DbTransaction进行封装，提供一种类似于TransactionScope的编程方式来解决这个问题。 阅读全文

摘要： 本篇文章介绍可以算是WCF 4.0基于限流（Throttling）的新特性，是在修订《WCF技术剖析（卷1）》的时候编写演示实例的时候发现的。这个特性没有出现在官方文档上面，至少在MSDN上的相关介绍依然是错误的。 阅读全文

摘要： 在《集成EntLib实现ASP.NET MVC的异常处理》我们实现采用EntLib的Exception Handling Application Block（EHAB）进行异常的处理，并导向指定的出错页面。在这篇文章中我们做一些改变，直接将处理过的异常消息显示在本页的ValidationSummary中。 阅读全文