DTO和實體框架

我的解決方案使用實體框架，並將EF模型轉換爲DTO對象以從UI層向上和向下傳遞。DTO和實體框架

不過我有一個設計問題：我有一個Person表和PersonUnavailibility表。一個人可以有一段時間，他們不可用。

我的PersonDTO對象具有PersonEF模型的所有屬性，以及List<PersonUnavailibilityDTO>對象。所以，當我找到我的人時，我也會得到那些不可用的人。

但是，如果我PersonUnavailibilityDTO有PersonDTO對象？所以如果我得到一個PersonUnavailibilityDTO對象，我可以看到它與哪個人有關？

如果是這樣，我會得到一個循環引用。我的PersonUnavailibilityDTO's個人財產，有他所有的PersonUnavailibility行的列表...，並且其中每一個，有一個PersonDTO，並且每個人都有一個列表....等等等等

什麼是最好的設計這種事情？只包含與父對象相關的子對象？

也就是說，只有PersonDTO有一個PersonUnavailibilityDTOs的列表，但PersonUnavailibilityDTO沒有PersonDTO？

2013-07-02 Craig

這取決於。

在大多數情況下，因爲你會從觀看的人的DTO的，將不再需要查看和unavailabilities總是通過人訪問。

但是，當它周圍是nescessary的人添加到您不可將訪問對象的其他方式。

儘量保持您的Dto儘可能小而簡約。

2013-07-02 06:18:45 JMan

可能的方法之一是有一個通用複合dto模型來攜帶所有可能的實體組合。

在失去結構嚴謹的價格，你會得到一個可重複使用的一個。

2013-07-02 07:10:22

作爲一般性建議，最好避免對象之間的雙向關係。

的風險是具有不同步的對象，即對象A點到B（或B的集合），但B不指向A - 典型地，將有一個空引用來代替。爲了防止這種情況發生，您必須始終保持關係的兩端同步，這是有代價的。

但是，當對象是不可變的（這可能與您的DTO的情況相同），因爲它們在創建時組成並且之後從未修改過，從而消除它們之間的差異風險，所以可以減輕這一點。

正如吉榮指出的那樣，我還是建議去爲最簡單可行的解決方案：PersonDTO -> PersonUnavailibilityDTO直到絕對證明了你所需要的反向關係。

2013-07-02 09:09:32 guillaume31

我更喜歡除去DTO的集合和添加服務方法來請求集合來代替：

function GetUnavailable(PersonID, Options) as IEnumerable(of PersonUnavailabilityDTO)

這樣

2016-02-06 12:51:12 Lightman

回答