RavenDB - 當我想要參考另一個根集合體

我一直在使用DDD知道，所以我對集合體的想法感到滿意。起初我也有煩惱周圍環繞我的頭不使用/堅持到其他根聚集的引用，但我覺得我在船上......所以：RavenDB - 當我想要參考另一個根集合體

存儲根骨料作爲一個文檔....檢查
使用含有不改變或很少改變性質的非規範化的引用....檢查

對於我確實希望有一個完整的參考另一根聚集的時候，我明白建議我堅持提及其ID，並可以使用RavenDB客戶端API的包括以retri有效地將所有實體均等。

處理該數據部分，我還沒有看到在我的實體類來處理這一點的最好辦法：

在使用[兩者產品和在我的課產品編號性質JsonIgnore]上產品，以確保它不會持續與該文件。
- 完整對象圖然後可以在存儲庫中被膠合到一起（使用API的含效率）或I可以注入一個服務到實體，將取產品懶惰地（可能N + 1次命中）
把它粘在一起在ViewModel中。我不喜歡這個想法，因爲如果使用不正確，最終可能會導致域中出現意外的NULL引用。
其他一些我看不到的明顯方式？

想法？

來源

2011-09-22 Mike Rowley

在DDD中至少有兩個有效的觀點。某些ppl鏈接根僅通過ID或其他有效密鑰進行聚合，其次是使用特定於平臺的對其他對象的引用。兩者都有自己的優點和缺點。

對於像RavenDb這樣的NoSql解決方案，使用第一種方法可能會更好，因爲第二種方法在技術上是錯誤的。

來源

2011-09-23 10:36:28

你會明確反對這裏推薦的設計，爲什麼做你想要一個Product屬性引用另一個聚合？它給你什麼？

來源

2011-09-22 18:29:46

使用產品是一個不好的例子，因爲您已經在很多非規範化的例子中使用了這個例子。在RavenDB Mythology Documentation（我意識到它仍然是草稿）中，提供了一個客戶的LastLogin的示例（2.1.4 - 什麼是非規範化）。「如果你真的需要完整的相關文檔，你需要明確加載它」。我同意，在實際需要時很難想到時間。正如你在我的問題中看到的那樣，當我確信我需要（作爲一個附帶案例）時，我正在詢問什麼是一個好的方法來做到這一點（明確加載它）。 –

RavenDB - 當我想要參考另一個根集合體

回答

相關問題