UML組合與SQL外鍵

以下圖像（即不可導航的組合關係）在域模型的早期階段UML類圖中是否有意義？UML組合與SQL外鍵

class

我想表達的，這是不可能做到Company.Accounts，但如果公司對象被銷燬，所有賬戶都將被破壞過。我的動機是避免Company類成爲某種God-Object反模式，如this question中討論的那樣。用數據庫術語說：有一個來自Account --> Company的外鍵。在實際的應用程序中，幾乎所有東西都歸公司所有，出於性能原因，我不希望懶惰/急切地加載公司的所有子集。

我想最終的圖可能會有一個IAccountRepository（見下圖），但我發現它負擔類圖將所有的東西放在那裏。想象一下，爲每個子集合添加額外的基礎設施類。類圖將變得不可讀！

class diagram2

你如何傳達想法領域模型中的那個負荷將是「間接」？它甚至去那裏？

關於此的任何參考或行業標準？

謝謝。

來源

2012-11-09 dstj

您正在將行爲建模與靜態模型混合使用。你Company和Account之間建立的關係是確定的，如果Company從未直接訪問Account，但如果你有功能Company訪問Account，那麼你的模式是錯誤的。

從我所知道的，沒有辦法模擬這一方Company是由Accounts組成，但帳戶實際上是存儲在另一個地方。您的第二張圖不正確，因爲如果Company由Accounts組成，則IAccountRepository應通過Company訪問它們，而不是直接訪問它們。

恕我直言，Account應該有從組成到IAccountRepositoryAccount，協會從Company到Account，並在ICompanyRepository.deleteCompany的序列圖，當一家公司被刪除，它的所有賬戶都將被刪除。

來源

2012-11-11 09:54:38 vainolo

謝謝。我想通過存儲庫傳達的是，應用程序將能夠直接加載「公司」和「帳戶」。帳戶屬於公司，它是數據庫中的NOT NULL外鍵約束，但我不想通過公司在每次需要帳戶ID ABC時訪問它們...我確信我理解您的意思是「帳戶應該有從IAccountRepository到帳戶的組成「，」IAccountRepository「不是」帳戶「的所有者，不是？ – dstj

在類圖中顯示您想要的內容是有問題的。我看到的唯一選擇是刪除組合鏈接中的「X」，併爲此鏈接添加註釋，說明帳戶是從「IAccountRepository」中獲取的，而不是直接從「公司」 – vainolo

UML組合與SQL外鍵

回答

相關問題