查詢閱讀模式

當使用CQRS和事件採購存儲不可知論選項。查詢閱讀模式

我使用NServiceBus發送命令和發佈事件，我已經配置的應用程序項目，聽取事件和RavenDB建立讀模式。

我會從RavenDB中讀取我的演示文稿項目，但是會將我的演示文稿層鎖定到使用RavenDB或其他事件偵聽器使用的任何其他位置，並且希望保持表示層不可知。

我本來想使用NServiceBus請求/響應，但各種事情我讀過溫暖反對這一點。

有沒有這方面的選擇？

編輯從評論

我在做什麼使用一個單獨運行的進程偵聽事件並保存結果正在建設的讀取模型ravendb。
我發現檢索這些構建模型的結果的唯一選項是讓我的演示對象（又名web api）連接到ravendb。這是我想要避免的。

爲什麼呢？

那麼，如果我想旋轉我的Web API的20個實例來平衡請求，每個實例都必須連接到ravendb - 除了我已經連接的許多讀取模型構建過程。使ravendb成爲瓶頸。

理想的情況下我會想要做的就是從我的web API發送一個請求，以獲得數據的應用程序隊列，等待數據回來的答覆的形式。這種方式我根本不關心我的應用程序進程在做什麼或他們如何存儲數據，我只是獲取數據。

有2篇文章我讀過有關這種做法 -

這一個說不要做 http://andreasohlund.net/2010/04/22/messaging-shouldnt-be-used-for-queries/

這人說去了 http://www.udidahan.com/2007/11/10/asynchronous-high-performance-login-for-web-farms/

來源

2014-04-26 Charles

您可以使用查詢處理程序或良好的舊版本庫（不是DDD版本） – MikeSW

謝謝，存儲庫只是一個固定數據源的掩碼 - 我必須遷移數據源保持相同的回購，並且它不那麼容易正如宣傳說的那樣。我發現查詢處理程序的所有示例都歸結爲回購和服務器上查詢數據訪問。也許你可以提供一個使用基於消息的查詢處理程序的例子嗎？ – Charles

首先，正確的Repository模式只與您的案例視圖模型中的應用對象一起工作，所以您可以在需要時真正切換數據源，並且您還需要完全不同的repo實現。查詢處理程序直接在DAL中查詢數據源。他們也返回視圖模型，並需要爲不同的數據源重寫。但是在這兩種情況下，表示層都與持久性分離，這就是你想要的 – MikeSW

如果你做得對，你正在選擇一個閱讀模型，它非常適合你手邊的閱讀任務。除非您認爲您要將其交換出去，否則請直接使用該產品！針對關係型讀取模型使用簡單的SQL接口（例如jdbc，ado.net）。將Cypher用於圖模型。對鍵值存儲使用本機API。不要再添加抽象;這首先是分隔讀寫的目的。

來源

2014-04-28 18:49:56

這是一個很好的觀點 - 只有演示文稿對象纔會知道他需要什麼樣的閱讀信息，他應該只是得到他需要的信息 – Charles

查詢閱讀模式

回答

相關問題