3）快取層如何設計
我們前面講過 了n-tier架構。在我們的程式當中，還可以設計乙個快取層。在去訪問資料庫之前，先看看快取層中有沒有資料，如果沒有的話，從資料庫取完資料回來，一 定要放在快取層當中乙份，下次就不用去資料庫了。如果對資料庫當中，某個資料更新了，同時一定要記住也更新一下快取當中的資料。這樣的話，既保證了快取的 資料是最新的，也保證了將來查詢時不用去查資料庫，減輕了對資料庫的壓力。 這裡有些問題，問題1，如果除了你的專案，還有其他的地方可以更改資料庫，怎麼辦？可以做乙個守護執行緒，發現某個表的版本變了，就重新把錶的資料載入回你 的快取。問題2,對於條件查詢，如何處理快取？比如30元到50元的衣服資料的第二頁。大家通常的做法是，把整個衣服表都載入到快取中，無非就是乙個 list，之後整個做個遍歷，把符合條件的選出來。為什麼要整個載入？因為別人還有可能要查20到40塊錢的第五頁的資料。問題3，專案a處需要看錶的 123列，b處需要看錶的456列，快取時就直接把123456列作為乙個表快取起來，供兩處使用。順便說一句，快取也可以快取。資料庫和服務 器，可以認為是大的倉庫，什麼都能找到，而快取可以看做是前端的商店，客戶經常要買的東西就存一部分在商店，這樣可以提高效率。如果商店沒有相應的商品， 也不用著急，因為我們後面的倉庫肯定有。
更多請見：
業務邏輯層快取應該設計
在業務制定的時候很少會切入快取設計這一環節,畢竟在指標不明確的情況這屬於一種過渡設計.畢竟快取切入有很多手段,在很多時候直接在web進行乙個頁面快取就有著非常高收益的效果.快取是一種橫向的資料處理應用,一般在設計中引入aop,ico的應用元件都可以在後期切入新增.但aop,ico在沒有比較豐富的經驗...
簡單利用Memcached進行快取層設計
正在考慮web應用快取層的設計，參考了不少資料，估計還是需要用到相對成熟應用廣泛的分布式快取memcached。在.net平台上早就有相對成熟的memcached客戶端產品，如beitmemcached和enyimmemcached，業餘時間看了一下原始碼，自己分析並呼叫一下並不困難。這裡簡單介紹一...
軟體設計 DAO層該如何設計
關於dao層的設計我現在也還是有點模糊，大大小小的專案也做了五六個了，負責的資料庫設計也有三四個了。在對dao層進行設計時採用過兩種方案 方案一 每一表對應乙個dao類 介面也可 每個dao將完成對該錶的增刪改查以及業務上要求的查詢操作。這麼設計的話如果表很多的話將會產生很多類，並且將會出現大量重複...