java dto 设计_java – 设计具有外键关系的DTO

免责声明：我不是ORM专家……

…但在经典的many-to-many relations中,您不需要第三个数据模型(UserGroupAssoc). User类将包含一组Groups：

public class User {

// ... user fields ...

List groups;

// ... getters/setters ...

}

如果还需要反向关系(一个组包含用户),Group类将如下所示：

public class Group {

// ... group fields ...

List users;

// ... getters/setters ...

}

再一次,这样做的经典方法是在集合中使用“域对象”(您的DTO)(用户和组而不是userId和groupId).

仅当关联表(User_Group_Association)包含除user_id和group_id之外的其他内容(可能是允许将用户添加到组中的某些授权代码,无论如何)时,通常需要第三个域对象：

user_id | group_id | auth_code

在这种情况下,UserGroupAssoc类可能具有以下结构：

public class UserGroupAssoc {

private User user;

private Group group;

private String authorizationCode;

// ... setters/getters ...

}

用户和组之间的多对多关系将转换为与这个新域对象的两个多对一关系.通常,首选使用域对象(用户和组而不是userId和groupId).

Which is the standard approach to achieve this scenario?

好吧,如果您使用的是ORM框架,它将成为框架执行它的标准方式.但由于您有自定义的ORM解决方案,因此很难说.

Is joining tables alright in the DTO design?

为什么应用层中的DTO设计会受到数据库中表的连接的影响？这是object-relational impedance mismatch的情况,也可能是law of leaky abstraction,因为您无法将关系域完全抽象为保持1：1对应关系的对象域.

Some have opinions that one DTO should correspond to only ONE table and the associated objects should be aggregated in the app layer. That has overhead of doing multiple object fetches from DB right?

ORM有一些限制(再次看到您可能遇到的某些问题的对象 – 关系阻抗不匹配),并且很难对域对象进行建模以适应关系数据库的约束,反之亦然.报告就是这个方向的好例子.

报告通常聚合来自多个表的数据.对于某些SQL连接,这当然没有问题,但是如何将结果映射到DTO？正如你自己说的那样……

Whenever the DTO exactly corresponds to a single table in the database, it is very straight forward

…但是报告结果不会映射到单个表,它必须映射到更多表中的片段.

根据您在应用程序中的需求,您最终可能会看到一些看起来很奇怪的类或者看起来很笨拙的SQL.您最终可能会运行比查询所需的更多查询以获取正确的对象模型和它们之间的关联;或者你可能有更多类似的DTO只是为了限制到数据库的次数并获得更好的性能.

所以我想说的是(我不是ORM专家的免责声明)并非所有应用程序都是ORM的良好候选者;但是如果你考虑继续它可能会考虑Hibernate / JPA如何解决这些问题,甚至可以继续使用它们.