我目前在建庫的項目，該項目將成爲DB密集的過程（性能測試已經進行了，並且需要高速緩存因此爲什麼我問）緩存策略查詢的數據
的我現在設置的方式是每個對象都單獨緩存，如果我想爲它們查詢對象，我將查詢傳遞給數據庫並返回所需的id。 （對於一些簡單的查詢，我已經緩存並管理了ID）
然後我用這些id命中緩存並將它們拉出來，任何丟失的對象都綁定到「where in」語句並觸發到數據庫;此時我使用缺少的ID重新填充緩存。
查詢他們自己最有可能是關於分頁/排序數據。
這是一個合適的策略？或者也許有更好的技術可用？
這是一個合理的方法，我已經走過這條路線，最好使用它來進行簡單的緩存。
但是，當您更新或寫入數據庫時，您將遇到一些有趣的問題，您應該仔細處理這些情況。
例如，如果用戶更新數據庫中的記錄，則緩存數據將會過時。在這種情況下，您將需要同時更新內存緩存或清除緩存，以便在下一個獲取查詢時刷新緩存。
事情也可能很麻煩，如果你例如用戶更新了客戶的電子郵件地址，它是在一個單獨的表，但通過外鍵關聯。
除了數據庫緩存之外，您還應該考慮輸出緩存。例如，如果您有一張顯示上個月銷售數據的表格，這種方式非常有效。該表可以存儲在另一個文件中，該文件包含在希望顯示該表的一堆其他頁面中。現在，如果您緩存與銷售數據表中的文件，當他們請求此文件的其它頁面，緩存引擎可以直接從磁盤和業務邏輯層甚至不被打到它牽回家。這一直不適用，但對自定義控件非常有用。工作模式
單位
它還有助於瞭解Unit of Work模式。
當你進出的 數據庫中提取數據時，它保持 跟蹤的你已經改變了什麼是重要的; 否則，該數據將不被寫入 回數據庫。同樣你 必須插入創建 新對象，並刪除您刪除的任何對象。
你可以用每個 改變你的對象模型更改數據庫，但這 會導致很多非常小的 數據庫調用，它最終被 很慢的。此外，它需要您 有一個交易打開 整個交互，這是 不切實際，如果您有一個業務 交易跨越多個 請求。如果您需要跟蹤您已閱讀的 對象，則情況更糟糕，因此您可以避免 不一致的讀取。工作
一個單元會跟蹤你的業務 交易可能影響 數據庫中做 一切。完成後，它會將 的結果作爲 的結果來計算出 需要執行的所有操作。
我不建議自定義緩存策略。緩存很難。根據您選擇的平臺，您可能需要選擇第三方緩存庫/工具。
如果您使用SQLServer，則可以使用SqlCacheDependency，在數據庫中的數據表發生更改時，緩存將自動重新填充。 這是SqlCacheDependency的鏈接
此鏈接包含類似的cache dependency solution。 （這是一個文件，而不是一個數據庫，你將需要做出一些改變按照MSDN的鏈接上時對數據庫緩存依賴性）
希望這有助於:)
當任何數據更新緩存更新 - 它也更新表格。我在這個項目中使用了存儲庫模式，並且所有的數據訪問都是通過這個方式進行的。它自己的存儲庫總是碰到緩存，然後db（如果緩存是空的或者數據正在更新） – TWith2Sugars 2009-06-03 15:15:31
如果你還沒有，選項可供您使用，爲什麼不考慮ORM？ – aleemb 2009-06-03 23:03:09