4

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

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

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

4

2 回答 2

3

就像设计中的一切一样，这取决于您的需求。

  • 如果您需要经常查看和绑定到子属性，并且希望开发人员尽可能轻松地使用您的 DTO，您可能需要显式工厂方法为您提供完全扩展的子属性。
  • 如果您想要代码的简单性，请不要扩展外键属性，而只需让开发人员根据需要通过键获取他们想要的子对象/集合。

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

Microsoft 的实体框架以及其他流行的业务对象框架通过延迟加载来处理这个概念——只有在代码调用时才获取完整的展开子属性。这可能是最灵活的解决方案，但有一点开销/滞后，因为无法在与父对象相同的数据库调用中获取子属性。这些当然不是纯粹的 DTO。

于 2011-03-22T13:41:44.257 回答
2

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

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

于 2011-03-22T13:39:39.763 回答