設計的DTO包含對象的名單

Project    Task 
    - Id     - Id 
    - Name     - Name 
    - List<Task>   - Project

項目有很多任務和任務有一個項目。

現在假設我想創建一個TodoListDTO數據傳輸對象。我原來的想法是這樣做的：

TodoListDTO 
    - List<Project>

似乎很簡單。然後我可以訪問每個項目中的任務列表。然後我在幾個地方讀到DTO應該儘可能平坦。但是，如何在不使用複雜對象的情況下建模？

相反TodoListDTO的，我可以有一個ProjectDTO，看起來像：

ProjectDTO 
    - ProjectId 
    - Name 
    - List<TaskId> 
    - List<TaskName>

但具有TaskID的和TaskNames似乎不方便單獨的列表，我看不出這是任何不只是有一個更好的在ProjectDTO上列出屬性。

什麼是處理這個問題的好方法？

2016-08-26 jrsowles

儘可能平坦並不禁止您正確建模問題。如果一個項目有任務和任務有一個項目，那麼我看不到你的初始設計有什麼問題。 – saarrrr

我寧願第一個。模塊化。因爲，如果您嘗試訪問應用程序中任意位置的項目列表，您最終將獲取其下任務的所有信息。這是不高效的。 – Reddy

那麼a * Data * ** Transport ** * Object *用於傳輸數據（f.i.導入/導出數據到特定的JSON/XML/..格式）。 EF的模型也是DTO（將數據從/傳輸到數據庫）。 DTO在這個問題上的意圖是什麼？ –

你以前的課程很簡單，也是標準的做法。你可以創建一個Context類來保存項目和任務列表。共三個班。

2016-08-26 22:39:25

您的意思是一個Context類，它有兩個單獨的列表（一個用於項目，一個用於任務）或一個項目列表，每個列表中的每個元素都有自己的任務列表？ – jrsowles

是的我的意思是兩個單獨的名單。但是，如果您的scenerio允許，則可以省略任務列表。標準的方式是Context包含所有實體類的列表。 –

另外，正如馬修所說，項目和任務之間也有多對多的關係。所以你可以設計一個關聯類來處理它。 –

你可以做的另一件事是創建的

ProjectTask 
    - ProjectId 
    - ProjectName 
    - TaskId 
    - TaskName

另一個域模型這可能與一個一對多的關係，幫助（也使許多一對多）和側跨混亂circluar項目 - >任務 - >項目 - >任務結構。從這裏你可以通過projectId讓你的API客戶端組完成所有ProjectTasks，並以這種方式處理它。

這就是說，我認爲你的原始方式是好的，但這是一個替代方案。

2016-08-26 23:18:46

回答