摘要： 作为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中。 阅读全文

摘要： 在项目开发中，我们会使用到很多的描述性文字，比如验证消息、错误消息和确认消息等，让这些文本消息具有可维护性具有重要的意义。在我们的项目开发中使用的是专门的一个维护消息的组件。在这篇文章中将会通过扩展现有的ValidationAttribute特性让ASP.NET MVC应用可以使用我们的消息组件来获取验证消息。 阅读全文

摘要： 谈到IoC和ASP.NET的集成，很多人会先后想到Ninject，不过我们个人还是倾向于Unity。这篇文章简单地介绍如果创建基于Unity的ControllerFactory。 阅读全文

摘要： 本篇通过自定义ASP.NET MVC的异常筛选器实现了与EntLib的EHAB（Exception Handling Application Block）的集成，使我们可以通过配置的方式来定义异常处理策略，并最终通过错误页面显示被处理过的异常信息。[源代码从这里下载] 阅读全文

摘要： 在《通过一个模拟程序让你明白ASP.NET MVC是如何运行的》一文中我通过一个普通的ASP.NET Web程序模拟了ASP.NET MVC的执行流程，现在我们通过类似的原理创建一个用于模拟WCF服务端和客户端工作原理的模拟程序。[源代码从这里下载] 阅读全文

摘要： 如果采用自我寄宿的方式，我们需要为每个寄宿的服务创建ServiceHost对象。但是一个应用往往具有很多服务需要被发布，基于单个服务的ServiceHost的创建将会变成一个很繁琐的事情。如果我们能够采用某种机制来读取所有配置的服务，并自动为它们创建相应的ServiceHost对象，这无疑是一种理想的方式。 阅读全文

摘要： ASP.NET MVC的路由系统通过对HTTP请求的解析得到表示Controller、Action和其他相关的数据，并以此为依据激活Controller对象，调用相应的Action方法，并将方法返回的ActionResult写入HTTP回复中。为了更好的演示其实现原理，我创建一个简单的ASP.NET Web应用来模拟ASP.NET MVC的路由机制。这个例子中的相关组件基本上就是根据ASP.NET MVC的同名组件设计的，只是我将它们进行了最大限度的简化，因为我们只需要用它来演示大致的实现原理而已。 阅读全文

摘要： IIS 7.0因引入WAS提供了对非HTTP协议的支持。这个对于WCF的服务寄宿来说意义重大，它意味着我们通过IIS/WAS寄宿的服务终结点不仅仅可以采用BasicHttpBinding、WSHttpBinding/WS2007HttpBinding等基于HTTP协议的绑定，也可以采用NetTcpBinding、NetNamedPipeBinding和NetMsmqBinding。 阅读全文

摘要： Unity是微软P&P部门开发的一个轻量级IoC框架，通过Interception机制可以实现基于三种拦截机制的AOP。不过Unity仅仅提供“显式”拦截机制，以致我们为了注册可被拦截的类型会多写很多代码和配置。本篇文章通过UnityContainer的扩展提供了一种“自动”拦截机制。 阅读全文

摘要： 在定义和寄宿WCF服务的时候会面临三个名称/命名空间，它们分别是ServiceContractAttribute、ServiceBehaviorAttribute和Binding的Name和Namespace属性，很对人对此不能很好地区分。 阅读全文

摘要： 现在我们通过一个实例来演示终结点的地址报头如何影响实现终结点选择的消息筛选机制。这个实例通过为服务端终结点指定地址报头实现针对客户端的授权，让经过许可的客户端才能访问这个服务。具体来说，我们将一个代码序列号的GUID作为终结点的地址报头。对于客户端发送的消息，只有具有相应的报头才能访问服务。 阅读全文

摘要： 终结点是整个WCF的核心，由经典的ABC三要素组成。作为表示地址的EndpointAddress，很多人仅仅将其看成是一个表示标识服务并且表示服务所在地址的Uri，其实服务标识和定位服务仅仅是EndpointAddress一个基本的功能，它不仅仅是Uri那么简单。 阅读全文

摘要： 作为.NET Framework的一部分，几乎每个版本.NET Framework的推出都会为WCF带来一些改变。针对于最新版本的.NET Framework 4.0，一些新的特性被引入到WCF。对于这些基于.NET Framework版本的更替而带来的针对WCF的变化，我个人是这么看待的：WCF在随着.NET Framework 3.0发布的时候就具有一个成熟的架构设计，可扩展性即使一个重要的衡量标准。基于后续版本的.NET Framework发布的WCF并没有像WF一样出现“革新”型的改变，很多都是利用了这个可扩展性的通信平台开发出来的新特性，WCF 4.0也不例外。 阅读全文

摘要： WCF所谓的安全审核就是针对认证和授权所做的针对EventLog的日志记录。我们不但可以设置进行审核的事件（认证成功/失败，授权成功或失败），还可以选择记录信息被写入的EventLog类型，即应用程序日志还是安全日志。WCF的安全审核是通过ServiceSecurityAuditBehavior服务行为实现的。 阅读全文

摘要： 在Managed模式下，可用服务的终结点通过发现代理来统一管理。客户端在进行可用目标服务探测和解析的时候直接向发现代理进行探测和解析请求就可以了。这篇文章通过一个简单的实例为你演示如果通过创建发现代理实现可用服务的实时维护。服务可以在上下线的时候自动注册和注销，客户端可以动态地向发现代理查询当时可用的服务。 阅读全文

摘要： 在《原理篇》我们对客户端如何监听通知，以及服务在上下线时如何发送通知从原理上进行了深入地剖析。我们现在通过一个简单的实例演示如何通过ServiceDiscoveryBehavior服务行为为寄宿的服务添加一个实现上/下线通知的AnnouncementEndpoint终结点，以及客户端如何通过对AnnouncementService服务的寄宿实现对通知的监听和接收。[ 阅读全文

摘要： 到目前为止，我们所介绍的都是基于客户端驱动的服务发现模式，也就是说客户端主动发出请求以探测和解析可用的目标服务。在介绍WS-Discovery的时候，我们还谈到另外一种服务驱动的模式，即服务在上线和下线的时候主动对外发出Hello/Bye通知。 阅读全文

摘要： 前面两篇我们分别介绍了可被发现服务如何被发布，以及客户端如果探测可用的服务。接下来我们通过一个简单的例子来演示如果创建和发布一个可被发现的服务，客户端如何在不知道服务终结点地址的情况下动态探测可用的服务并调用之。 阅读全文

摘要： 在《服务如何能被”发现”》中我们着重讨论了可被发现的服务（Discoverable Service）如何通过ServiceDiscoveryBehavior行为的服务通过标准终结点DiscoveryEndpoint发布出来。现在我们来谈服务发现的另一个方面：客户端如何动态地探测可用的目标服务？ 阅读全文