此模式出自《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》的中文版)
以上是我個人看了緩存控制器模式后對于這種模式的想法，和書中表達方法有所不同，書中對于此種模式講解更為的深入也更為的全面，能夠想深入了解這種模式的話，可以去看看英文版，或者等中文版出版。