数据传输对象中的属性是否应该扩展外键或简单地公开其主键

Question

我有一个 EmployeeDTO 代表数据库中的 Employee 记录。Employee 表与 Department 存在关系，与 Permission 存在一对多关系。

在我的实体中，它们表示为完全扩展的部门属性和完全扩展的权限对象列表。

问题是 DTO 是否应该具有 DepartmentId 的完全扩展的 DepartmentDTO 属性？DTO 是否应该具有 PermissionId 列表的完全扩展的 PermissionDTO 属性列表？

Answer 1

就像设计中的所有内容一样，这取决于您的需求。

• 如果您需要经常查看和 绑定到子属性，您想要 使它尽可能容易 开发人员使用您的DTO，您可以 想要明确的工厂方法 您完全扩展了子属性。
• 如果您想简化代码，请不要 扩展外键属性并 只是让开发人员生孩子 他们想要的物体/收藏品 根据需要。

  您可能会遇到递归问题；您是否还要扩展Department对象的所有外键属性？如果在Department的子类中引用另一个EmployeeDTO，该怎么办？

  Microsoft的Entity Framework以及其他流行的业务对象框架通过延迟加载来处理此概念-仅在代码要求的情况下，才获取完整的扩展子属性。这可能是最灵活的解决方案，但是开销/滞后时间很小，因为无法在与父对象相同的数据库调用中获取子属性。当然，这些并不是纯粹的DTO。

Answer 2

是和否。这取决于调用以及您是否在每次调用中都需要所有额外属性。它还可能取决于您使用的 ORM 技术，该技术可以实现延迟加载并可以影响您的决定（如果您传递直接实体对象，尽管它是 不建议).

创建一个包含所有必要属性的案例 DTO 和一个或多个公开更多功能并用于其他方法的 DTO 对象是很常见的。例如，我有一个 BasicUser 类只包含 UserName 和 DisplayName 我有 User 其中包含更多包括 Permissions 和 继承 来自“BasicUser.