1. 背景
由於專案進度趕得比較緊，而且第一次自己設計系統的架構，剛開始考慮的並不完全，主要想著先把系統的功能實現了再說。因此剛開始設計系統的時候並沒有考慮快取的問題，但是對已乙個web系統，快取不僅可以大大的減少資料庫的壓力，也可以很大程度的提高系統的響應時間。現在系統的功能完成的基本差不多了，因此現在需要為系統新增快取，但是由於系統功能已經完成的差不多了，**寫的也很多了，所以現在新增快取確實顯得比較困難了。
先說說我們當前系統的整體框架結構吧。
從圖中可以清楚的看出，我們目前採用的架構比較簡單，所有的請求都通過.htaccess檔案**到index.php然後在index.php檔案中啟動**函式，通過請求的將請求分配到特定的』server』執行特定的action，在此action裡呼叫乙個服務從資料庫裡取出資料返回給客戶端。下面是當前系統的類圖(為了顯示出呼叫的方法，所以有點不規範)。
2. 新增快取
新增快取的方法有很多，最讓人想到的就是直接在dao層新增，在從資料庫取資料之前，首先先從快取取，如果快取沒有的話再從資料庫取，然後放到快取裡。另一種策略是在service層新增快取，也就說從將從dao層取出的取出的資料進行拼裝之後放到快取裡。
首先分析一下兩種方案的優缺點：
第一種方案：
優點：首先在dao層新增快取對每條sql的執行結果進行快取，快取的粒度比較小，快取的命中率會比較高。
缺點：每個sql查詢資料不一樣，則可能本來是同乙個資訊，但是可能僅僅是多了乙個欄位確又多了一條快取記錄，這是很大的浪費，畢竟快取的成本還是比較高的。其次如果直接在dao層進行快取，有些地方其實是不想進行快取的，那麼這樣就比較不方便控制了。
第二種方案：
優點：在service進行快取，首先是在原來系統的基礎上新增**比較少，其次對拼裝好的資料快取由於service的引數一般變化不大，快取的資料就會比較少，命中率也不錯。
缺點：快取的粒度比較大，命中率不會那麼理想，而且快取的重用性也比較差。
綜合上面的分析基本可以知道無論是在dao層還是service層進行快取都既有優點又有缺點，最後經過考慮結合兩者的優點，抽象出乙個快取層，在快取層裡控制是否進行快取，以及快取的邏輯，同時將快取的物件改為資料庫對應的乙個乙個物件，這樣快取物件的重用性以及命中率都有很不錯的效果。
下面是新增快取後的類圖：
在原來的框架基礎上再service裡直接呼叫cacheserver載入指定的cache，原來的service邏輯不用改變，只有叫原來呼叫dao的改為呼叫cache即可。
到此快取基本已經新增完成，編碼也完成了，使用起來目前感覺還可以，又不合適的地方希望讀者可以多多交流。
最後感謝文章的博主，給了我很到的啟發。
應用程式快取 AppCache
html5提供了一系列的特性來支援離線應用 localstrorage web sql indexed database 需要快取的資源都放在manifest檔案中,cache manifest 以上折行必需要寫 cache 這部分寫需要快取的資源檔案列表 可以是相對路徑也可以是絕對路徑 index...
為MFC應用程式新增析構函式
mfc編寫的智慧型裝置應用程式，有些自己建立的gdi資源需要釋放，以免造成記憶體洩露。這樣有些 想放到主對話方塊的析構函式中。這時會發現找不到主對話方塊的析構函式，只能看到建構函式。這就需要自己來為主對話方塊新增析構函式。如 標頭檔案中新增 virtual cconfontchdlg 一定要加上vi...
前端應用程式快取 cache manifest
html5新增，他將程式所需的html css js 等儲存到瀏覽器中。他不會隨著瀏覽器清快取而被清除，老資料會被最近一次的訪問的新資料代替掉。一 首先建立乙個清單 包含程式依賴的所有url 二 在程式的主頁面設定manifest屬性，指向清單檔案 三 清單檔案首行必須以 cache manifes...