设计包含对象列表的 DTO答案

【问题标题】：Designing DTOs that contain lists of objects设计包含对象列表的 DTO
【发布时间】：2016-08-26 22:25:11
【问题描述】：

假设我有以下领域模型：

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

项目有很多任务，任务有一个项目。

现在假设我想创建一个 TodoListDTO 数据传输对象。我最初的想法是这样做：

TodoListDTO
    - List<Project>

看起来很简单。然后我可以访问每个项目中的任务列表。然后我在几个地方读到 DTO 应该尽可能平坦。但是如果不使用复杂的对象，我该如何建模呢？

代替 TodoListDTO，我可以有一个类似于以下内容的 ProjectDTO：

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

但是拥有单独的 TaskIds 和 TaskNames 列表似乎很不方便，而且我不认为这比在 ProjectDTO 上拥有一个 List 属性更好。

有什么好的方法来处理这个问题？

【问题讨论】：

尽可能平坦并不妨碍您正确建模问题。如果一个项目有任务，而任务只有一个项目，那么我认为您的初始设计没有任何问题。
我更喜欢第一个。模块化.. 因为，如果您尝试在应用程序中的任何位置访问项目列表，您最终将获取其下任务的所有信息。效率不高。
那么一个 Data Transport Object 用于传输数据（f.i. 将数据导入/导出到特定的 JSON/ XML/.. 格式）。 EF 的模型也是 DTO（从/向数据库传输数据）。问题中 DTO 的意图是什么？
希望将 DTO 与实体模型分开。我不会只公开一个 List.
好点。我在想我实际上会公开 List，其中 ProjectDTO 仅具有 Name 等基本属性。

【解决方案1】：

你可以做的另一件事是创建另一个领域模型

ProjectTask
    - ProjectId
    - ProjectName
    - TaskId
    - TaskName

这可以帮助处理一对多关系（也允许多对多）并避免令人困惑的循环项目->任务->项目->任务结构。从这里您可以让您的 API 客户端按 projectId 对所有 ProjectTask 进行分组并以这种方式进行处理。

话虽如此，我认为你原来的方式很好，但这里有一个替代方案。

【讨论】：

【解决方案2】：

您以前的课程很简单，而且是标准的做法。您将创建一个 Context 类来保存项目和任务列表。一共三个班。

【讨论】：