在這種情況下可以使用任何設計模式嗎？

Question

我們有一個長期處於積極開發/維護狀態（如十年）的系統（Java Web應用程序）。

我們正在研究的是爲Web應用程序實現一個RESTful API。這個使用Jersey的Web應用程序將是一個單獨的項目，意圖是它應該能夠與主應用程序一起運行或部署在雲中。由於我們的應用程序的性質和年齡，我們不得不在數據庫（postgres）之上實現一個（稍微）全面的緩存層，以幫助減少負載。無論如何，對於RESTful API，這個想法是GET請求將首先進入緩存而不是數據庫來保持數據庫的加載。

緩存將以一種方式填充，以幫助確保註冊的API用戶將需要的大部分內容都應該放在那裏。

如果存在高速緩存未命中，則應從數據庫中檢索所需數據（還要輸入進程中的高速緩存）。

顯然，我的代碼中的RESTful端點方法應該保持透明。我們想出了創建'Broker'來處理與數據庫和緩存的通信的想法。 REST層將簡單地通過ID（如果想要檢索）或填充的Java對象（如果希望插入/更新）並且代理將負責檢索/更新/無效等。

還有問題的可擴展性。首先，API將與其他服務器共存，因此訪問數據庫不會成爲問題，但是如果我們部署到雲中，我們將需要一個不同的代理實現來與系統進行通信（即數據庫）以不同的方式（可能通過使用內部API）。

我已經對如何實現這一點有了一個粗略的想法，但它讓我感到可能是一個適合的模式可能存在的問題。如果我可以按照既定模式而不是提出自己的解決方案，那可能是更好的選擇。有任何想法嗎？

Answer 1

沒有模式。只需隱藏接口後面的初始數據庫服務，圍繞其預期行爲構建測試，然後切換使用緩存層的實現。我想依賴注入將是最好的幫助你做到這一點？

Answer 2

聽起來像裝飾模式將滿足你的需要：http://en.wikipedia.org/wiki/Decorator_pattern。

您可以創建一個DAO接口進行數據訪問，是這樣的：

Value get(long id); 

，首次創建直接DB實現，然後創建一個緩存實現其調用底層DAO例如，在這種情況下，它應該是DB實現。

緩存實現將努力讓自身的被管理高速緩存，並從墊層DAO如果失敗值。

因此，您的舊應用程序或REST都只能看到DAO接口，而不知道任何實現細節，並且將來可以自由更改實現。

Answer 3

的Ehcache便是這樣，它調用SelfPopulatingCache緩存的實現。

請求的是緩存，而不是數據庫。然後，如果有緩存未命中，Ehcache將以您的名義調用數據庫（或您擁有的任何外部數據源）。

你只需要實現CacheEntryFactory其中有一個方法：

Object createEntry(Object key) throws Exception; 

所以顧名思義，實現了Ehcache這個概念有一個相當標準的工廠模式...

Answer 4

最好的設計透明緩存HTTP請求的模式是使用anHTTPcache。