存儲庫模式和1：1關係

我當前爲每個數據庫表和一個相應的數據類（用於傳遞數據的對象）創建一個存儲庫。存儲庫模式和1：1關係

我最近開始使用一些1對1關係，但我不確定實現它們的最佳方式是什麼。

例如

如果我在1用戶表和UserSettings表：1的關係。

// Data classes (Holds all the field value for the table) 
    public class User 
    { 
     public int UserId { get; set; } 
     public string Name { get; set; }  
    } 


    public class UserSettings 
     { 
      public int UserId { get; set; } 
      public bool SomeSetting { get; set; }  
     }

問題：

我應該總是通過用戶對象操縱UserSettings對象，或者我應該能獨立操縱他們？
我應該在UserSettings對象中包含主鍵字段嗎？
我應該在User對象中存儲對USerSettings對象的引用嗎？
我是否爲User和UserSettings製作兩個回購協議，還是處理Users Repo中的所有內容？

來源

2012-01-16 chobo

將用戶設置與用戶分開的目的是什麼？什麼系統只消耗登錄上下文以外的用戶設置？ – arootbeer 2012-01-16 19:47:07

我想我可以使用一個更好的例子 – chobo 2012-01-16 20:21:16

我懷疑它 - 'User' /'UserSettings'可能是圍繞1：1關係的唯一最好的問題。看到我的答案。 – arootbeer 2012-01-17 04:48:00

我唯一一次發現聚合根之間1：1關係有用的時候，關係兩邊的聚合根由不同的域管理。他們必須共享相同的主鍵，因此，如果他們都由同一個域管理，那麼他們是根據定義部分相同的聚合根。我認爲你需要從另一個角度來處理這個問題：

是否User對象只對這個應用程序存在？
您是否期望永遠如此？

如果User是完全駐留在此網域中的一個概念，那麼沒有理由有具有1 UserSettings aggretate根：用User 1的關係;您只需製作User.Settings即可獲取該User的UserSettings。（當然這消除了對存儲庫的需要 - 它成爲UserRepository的責任來滋潤UserSettings當它水合物一切都在User人）

但是，如果User最終會通知會議對多個域，那麼User需要表示其自己的域，您的應用程序將使用的服務。然後，您會非常需要將此應用程序的UserSettings與其他應用程序的應用程序分開。 User不是特定於此應用程序，但該User的UserSettings是。

注意 - 在此時不重構你的項目，如果回答問題1和2上面是「不」，那麼你應該使UserSettings一個單獨的聚合根內的利益相同的域，以便在您最終將User移入其自己的域時創建無縫過渡。

來源

2012-01-17 04:48:17 arootbeer

因此，如果我通過User.Settings「保溼」UserSettings對象，用戶設置將保持混合到Users表中嗎？ Settings對象只是一個容器/值對象來傳遞代碼中的數據嗎？ – chobo 2012-01-18 17:30:54

存儲庫是一個持久性外觀 - 無論你有一個表還是多個表本身都不是應用程序設計的考慮因素。正如伊恩31也提到的那樣，你似乎正從錯誤的方向接近這個問題。做出關於「用戶」所屬的決定，然後圍繞該決定設計您的域名。根據數據庫的要求做出關於數據庫設計的決定。您在進行模式設計時所問的問題僅僅是「我應該如何存儲這個？」，而不是「我應該存儲什麼？」 – arootbeer 2012-01-18 21:23:10

究竟你通過「通過用戶對象去」是什麼意思？
恕我直言，沒有。
你可以，但我不認爲你應該。你有什麼理由想知道這些設置屬於哪個用戶？你唯一想知道的是--imho - 是你堅持它的時候。在你的數據庫中，你需要知道UserSettings屬於哪個用戶。在你的模型中，我認爲你可以滿足單向關係
你應該只爲每個聚合根目錄創建一個倉庫，在你的情況下，'用戶'可以是一個聚合根目錄。 UserSettings是-imho甚至不是一個實體，而是一個值對象。

來源

2012-01-16 19:45:01

對於q1，我的意思是我必須創建一個User對象並粘貼UserSettings對象來更新設置，或者它可以是獨立的（即在UserSettings表上運行直接更新查詢）。因此，子表中的1到1關係是價值對象，我應該這樣對待他們？ – chobo 2012-01-16 19:54:28

我現在爲每一個數據庫表

存儲庫...

//數據類（包含所有字段值表）

看來你採用的是自下而上的（數據庫優先/數據庫中心）方法，這在DDD中並不常見。正如域名驅動設計所暗示的那樣，您通常寧願從建模您的域開始，充實您的聚合，聚合根和實體。

聚合根通常有自己的存儲庫，而常規實體通常沒有。要知道一個實體是否應該是一個聚合根，你必須問自己，這個對象是否將成爲應用程序中的主要入口點之一，並且有一組相關對象圍繞着它並只能通過遍歷它而獲得。

用戶是聚合根的明顯候選人。相比之下，用戶設置不是IMO的根，它屬於用戶的影響範圍。我會讓它成爲用戶聚合的一部分，並且只能通過遍歷用戶來獲得。這意味着在User中引用了UserSettings，但不一定是相反的。

來源

2012-01-18 12:34:18 guillaume31

我會問自己，如果一個UserSettings可以存在與一個關聯的用戶，和/或用戶總是有一個關聯的UserSettings。如果是這樣的話，UserSettings很容易成爲用戶聚合的一部分，而不是單獨的聚合本身。是的，在數據庫中，他們很可能會以不同的表格與他們之間的1：1關係，但這是存儲庫實施的特定關注點。您的域模型可以考慮用戶的UserSettings部分。

來源

2012-01-20 22:20:56

存儲庫模式和1：1關係

回答

相關問題