此模式出自《Ajax patterns and best practice》，这个模式非常具备实际意义，为客户端的缓存实现做出了指导，和以往在使用传统B/S结构进行开发时所做缓存的思路有一个改进点，:)。
在传统的B/S结构的应用中，为了提升系统的响应效率，经常会使用页面分块的缓存方式，在具体的实现上象经常采用oscache这样的东西来对页面的块进行缓存，将缓存的内容放入服务器端，当客户端再次请求时则可以直接从缓存中获取生成的页面块，而无需经过后台的一堆的处理，这种缓存方式对于系统效率的提升非常的明显，基本上达到了生成静态页面的效果。
而在《Ajax patterns and best practice》书中，提出了一种不同视角的缓存控制器模式，它是采用客户端做缓存的方式，当然，服务器端也同时做，这样的视角比较独特，以前还真没考虑过客户端来做缓存，先来说说采用了这种模式后的效果再来看看怎么实现吧：
效果
采用了缓存控制器模式后，客户端提交请求，服务器端返回相应的数据或页面片段，当客户端再次提交请求时，如服务器端此部分的数据或页面片段没发生变化，那么客户端将直接从客户端的缓存中获取数据或页面片段。
这样看来和传统的B/S结构缓存所起到的效果有什么不同的地方呢？就在于客户端也做了缓存，这就使得在数据没有修改的情况下可以减少流量的产生，而在传统的B/S结构的缓存策略中只是提升了服务器端的响应，但流量仍然是同样的。
实现
熟悉缓存策略实现方法的同学们在知道这种效果后基本上也就能想到怎么去实现了，:)，只是以前可能没有这么考虑过。
实现上首先在客户端建立对应key的缓存方式，也是类似Map的方式，当客户端发起请求时，将key也发送给服务器端，服务器端根据这个key值来判断是否需要重新获取数据或页面片段（和token方式类似），如需要，服务器端则返回数据或页面片段，如不需要，服务器端则直接返回一个不同的状态码，客户端根据服务器端返回的状态码来决定是从缓存中获取，还是获取服务器端返回的数据或页面片段，同时更新key值以及将数据或页面片段放入缓存中。
:)，按照这样的实现方式，如果js也有一个和oscache这些类似的缓存框架就好了....
来看看书中关于实现缓存控制器模式模型的一段描述：
"一种更好的方法是使用HTTP验证模型（HTTP Validation model）。该模型在每次发送响应时都会添加一个标签（ticket）来保证数据的唯一性。如果客户端想要再次下载内容，它将最后下载的标签发送给服务器。服务器端比较发送来的这个标签和它当前持有的标签是否一致。如果标签是一致的，服务器端就发送一个HTTP 304代码，指示出请求的内容没有发生变化。在这种情况下，客户端能够从缓存中获取旧的内容，并将它作为最近和最好的内容展现给用户。HTTP验证模型仍然需要一个HTTP请求，但是它不会带来重复生成和发送内容的代价。"
以上文字摘自即将出版的《Ajax模式和最佳实践》。(也就是《Ajax patterns and best practice》的中文版)
以上是我个人看了缓存控制器模式后对于这种模式的想法，和书中表达方法有所不同，书中对于此种模式讲解更为的深入也更为的全面，能够想深入了解这种模式的话，可以去看看英文版，或者等中文版出版。