复合 DTO 中的 DTO 应该通过主键还是通过对象引用相互引用？
建议传输对象不应包含对其他传输对象的对象引用。相反，他们应该使用其他传输对象的主键作为外键字段。
以 Order 和 Customer 作为实体的简单示例
显然，包含没有客户详细信息的订单列表的 OrderListDTO 将包含订购客户详细信息的外键。
复合 DTO OrderWithCustomerDTO 将具有对 OrderDTO 和 CustomerDTO 的对象引用。但在这种情况下，嵌入的 OrderDTO 本身是否应该有一个对其 CustomerDTO 的对象引用？或者应该使用订购客户的主键？
对象引用的指示
一个优点是客户端可以直接使用传输对象，例如作为表示模型。我倾向于接受这种方法来传输始终完全独立的对象，例如具有相关 DTO 的复合 DTO 或完整的树。客户可以信赖其独立性。客户端根本不需要对传输对象进行后处理。
将主键指示为外键
优点是内部和外部引用的处理方式相同。我倾向于需要这种方法来传输可能包含外部引用的对象，例如具有外部 childId 的子树。客户端必须迭代完整列表才能解析外部 childId。
使用树或子树的更复杂示例
现在讨论的传输对象是树或子树。从技术上讲，它是一个节点列表。
如果传输对象中的节点通过对象引用（如下面的 NodeTOWithObjectReferences）相互引用，可以吗？
public class NodeTOWithObjectReferences implements Serializable {
private long id;
private NodeTOWithObjectReferences parent;
private List<NodeTOWithObjectReferences> children;
}
或者传输对象必须用外键字段（如下面的 NodesTOWithForeignKeys）替换每个对象引用？
public class NodesTOWithForeignKeys implements Serializable {
private List<NodeDetail> children;
}
public class NodeDetail implements Serializable {
private long id;
private long parentId;
private List<Long> childIds;
}
（我选择传输对象来封装来自客户端的域模型并提供客户端特定的数据视图。）
There is a recommendation that transfer objects should not contain object references to other transfer objects. Instead, they should use the primary keys of the other transfer objects as foreign key fields.
Simple example with Order and Customer as entities
Clearly, an OrderListDTO containing a list of orders without customer details will contain foreign keys to the details of the ordering customers.
A composite DTO OrderWithCustomerDTO will have object references to an OrderDTO and to a CustomerDTO. But should the embedded OrderDTO itself have a object reference to its CustomerDTO in this case? Or should it use the primary key of the ordering customer?
Indication for object references
One advantage is that the client can directly use the transfer object, e.g. as presentation model. I tend to accept this approach for transfer objects that are always completely self-contained, e.g. a composite DTO with related DTOs or a complete tree. The client can rely on the self-containment. The client doesn’t need to post-process the transfer object at all.
Indication of primary keys as foreign keys
The advantage is that internal and external references are treated the same way. I tend to require this approach for transfer objects that might contain external references, e.g. a subtree with external childIds. The client must iterate over the complete list to resolve the external childIds.
More complex example with a tree or subtree
The transfer object in question now is a tree or subtree. Technically, it's a list of nodes.
Is it ok if the nodes in the transfer object reference each other by object references like the NodeTOWithObjectReferences below?
public class NodeTOWithObjectReferences implements Serializable {
private long id;
private NodeTOWithObjectReferences parent;
private List<NodeTOWithObjectReferences> children;
}
Or must the transfer object replace EVERY object reference by a foreign key field like the NodesTOWithForeignKeys below?
public class NodesTOWithForeignKeys implements Serializable {
private List<NodeDetail> children;
}
public class NodeDetail implements Serializable {
private long id;
private long parentId;
private List<Long> childIds;
}
(I opted for transfer objects to encapsulate the domain model from the clients and to provide client specific data views.)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您能否附上此建议来源的链接？至少对我来说并不明显。
在我当前的项目中，我使用包含对象引用的传输对象。这很方便，而且我还没有遇到这种方法的任何问题。
Could you attach a link to the source of this recommendation? It's at least not obvious to me.
In my current project I use transfer objects which contain object references. It's convenient and I haven't met any problems with this approach yet.