数据传输对象中的属性是否应该扩展外键或简单地公开其主键
我有一个 EmployeeDTO 代表数据库中的员工记录。 Employee 表与 Department 存在关系，与 Permission 存在一对多关系。
在我的实体中，它们表示为完全扩展的部门属性和完全扩展的权限对象列表。
问题是 DTO 是否应该具有 DepartmentId 的完全扩展的 DepartmentDTO 属性？ DTO 是否应该具有 PermissionId 列表的完全扩展的 PermissionDTO 属性列表？
I have an EmployeeDTO that respresents an Employee record in the database. The Employee table has a relationship to a Department and a 1-to-many relationship to Permission.
In my entities, these are represented as a fully expanded Department property and a List of fully expanded permission objects.
The question is should the DTO have a fully expanded DepartmentDTO property of a DepartmentId? Should the DTO have a list of fully expanded PermissionDTO properties of List of PermissionId?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
是和否。这取决于调用以及您是否在每次调用中都需要所有额外属性。它还可能取决于您使用的 ORM 技术，该技术可以实现延迟加载并可以影响您的决定（如果您传递直接实体对象，尽管不推荐）。
创建一个包含所有必要属性的案例 DTO 和一个或多个公开更多功能并用于其他方法的 DTO 对象是很常见的。例如，我有一个
BasicUser类，其中仅包含UserName和DisplayName，并且我有User，其中包含更多内容，包括权限和继承来自`BasicUser。Yes and No. It depends on the call and if you would need all extra properties in every call. It can also depends on the ORM technology you use which can implement lazy loading and can affect your decision (if you are passing straight entity objects although it is not recommended).
It is common to create one case DTO containing all necessary properties and one or more DTO object that expose more functionality and are used it other methods. For example, I have a
BasicUserclass which only containsUserNameandDisplayNameand I haveUserwhich contains more includingPermissionsand inherits from `BasicUser.就像设计中的一切一样，这取决于您的需求。
绑定到子属性，你想要
使其尽可能容易
开发人员使用您的 DTO，您可以
想要显式工厂方法给出
您完全扩展了子属性。
扩展外键属性和
让开发者得到孩子
他们想要的对象/集合
根据需要。
你可能会遇到递归问题；您是否也扩展了 Department 对象的所有外键属性？如果在 Department 的子类中引用另一个 EmployeeDTO 怎么办？
Microsoft 的实体框架以及其他流行的业务对象框架通过延迟加载来处理此概念 - 仅在代码调用时才获取完整展开的子属性。这可能是最灵活的解决方案，但有一点开销/滞后，因为无法在与父对象相同的数据库调用中获取子属性。这些当然不是纯粹的 DTO。
Just like everything in design, it depends on your needs.
bind to child properties and you want
to make it as easy as possible for
developers to use your DTOs, you may
want explicit factory methods to give
you fully expanded child properties.
expand the foreign key properties and
just let developers get the child
object/collections they want by key
as needed.
You may run into problems in recursion; do you also expand all the foreign-key properties of the Department object too? What if there is a reference to another EmployeeDTO in a subclass of Department?
Microsoft's Entity Framework, as well as other popular business object frameworks, handle this concept by lazy loading -- only fetch the full expanded child property if it is called for by the code. This is probably the most flexible solution, but has a little overhead/lag as child properties can't be fetched in the same database call as the parent object. These are of course not purely DTOs.