緩存是一個橫切關注點，是否應該變成一個Web服務？緩存服務是否應該存在？
這個問題可能有點奇怪，但我覺得在SOA中，服務應該基於業務解決方案進行識別，並且我們不應該公開僅負責緩存對象的服務。這似乎不是一個商業功能。如果有的話，它似乎是一個性能改進。
我們是否應該引進和實施一項服務來緩存數據？難道這不妨礙您的域模型本身？我的意思是每當你需要一個對象被緩存在另一個服務中時，你將不得不將這個類移動到cacheService。
這是什麼意見？
我不認爲這是一個好主意，通常緩存的概念是使數據可用並使其更接近使用點。將其作爲一種服務或其他服務模型推向真正的軟件，傳統意義上限制了這種能力。
緩存需要快速，本地和容易獲得。
專用緩存服務仍可能比使用數據庫更快。 – 2010-03-02 16:59:55
更接近其使用的緩存可能會更快 – Aneesh 2010-03-02 17:06:28
我認爲提高用戶的性能是一項業務功能。我認爲你的問題的確是你是否應該將緩存分解爲單個服務，還是將它內部地分配給其他服務。答案一如既往，這取決於。但它肯定可以有一個專門的緩存服務。例如，Google爲memcache這樣做。
編輯：再次，有不止一種方法皮膚貓。你不一定必須緩存最終的Person對象。另一種可能性是使用緩存服務來呈現數據，比如PDF帳戶聲明。例如，Hi5（社交網站），uses memcache來緩存完整準備的用戶配置文件。
如何在這種情況下管理我的域模型。例如：假設假設我有一個Person類，它永遠不會改變，我有一個不斷變化的賬戶類。我想緩存我的人員類，它現在可以從其緩存的其他服務中緩存。如何將賬戶的變更持續到數據庫（從OO和ORM的角度來講）。 如果我沒有緩存Person類（或者使用ORM自己的cachine機制），我會通過ORM查找Person並更新帳戶的值。持久性將是透明的。 – Aneesh 2010-03-02 17:04:49
透明的直寫式高速緩存是您可能想要的，而且這些高速緩存的複雜程度可以想象得到。如果您使用的是Java，請看看Terracotta。 – 2010-03-02 17:17:54
是的！同意。謝謝。 – Aneesh 2010-03-02 17:39:06
我同意你的看法，即Web服務應該公開業務功能。緩存Web服務的想法似乎是一個壞主意。
從使用的角度思考這個問題，這是什麼意思呢？這似乎意味着客戶端首先會訪問緩存Web服務來獲取對象。如果它不在那裏，他們需要從真正的Web服務中獲取它，然後將對象「推回」到緩存中？這是問很多客戶。任何緩存工作流程都應該對客戶端透明。
但是，如果您談論的是支持一些相關Web服務的緩存，這些緩存對客戶端「隱藏」（和透明），僅用於使Web服務的整個系列更具響應性，那麼可以一個好主意。
爲了回答第一個問題，沒有消費者會打到真正的服務。真正的服務必須打另一個服務來查找自己的域對象，因爲它被該服務緩存。現在，這意味着我的域對象已經分成兩個服務。 我不確定我是否明白「支持與緩存相關的網絡服務」意味着什麼。如果你的意思是支持一個真正的Web服務與提供緩存的另一個Web服務，是的，我的意思是。但是這個webservice不會隱藏其他客戶端。但有可能他們選擇不直接擊中它。 – Aneesh 2010-03-02 17:16:10
兩跳？瘋。它會死亡。 – duffymo 2010-03-02 17:24:55
如果客戶打算使用該服務訪問真正的Web服務，我並不認爲將緩存公開給外部任何人作爲Web服務的好處。對於選擇直接訪問緩存ws的客戶，他們仍然需要轉到真正的ws緩存未命中。爲什麼不通過首先公開緩存來讓所有對客戶端透明？您仍然可以享受緩存的好處，而不會增加客戶端的複雜性。 – Vinnie 2010-03-02 17:47:20
絕對同意。作爲一個門面，完全有保證。但我的關注主要是關於緩存域對象的服務。屬於其他服務的域對象，但放入緩存服務中，所有緩存都由該服務完成。因此，不是一個門面，這個服務最終被其他服務所使用，以便查找他們的域對象。 – Aneesh 2010-03-02 17:10:53
作爲前瞻性的服務，應該避免使用「一切皆大」的反模式。作爲後端黑盒緩存服務的「一切皆大桶」可能是另一回事。 – 2010-03-02 17:13:06