JPA实体和/与DTO

Question

在这些情况下,帮助决定何时使用DTO以及何时使用实体的一般想法是什么？

1. UI /服务器端java调用服务.它应该获得/发送实体或DTO吗？
2. 调用服务的Web服务.服务是否应接受实体或DTO？

我喜欢阅读传递实体的代码:

1. 更简单的传递,不需要映射到DTO
2. 不需要额外的课程
3. 已经定义了与其他实体的关系,因此不需要将相关的DTO组合到一个DTO中
4. 只是POJO

但是有关于DTO映射到实体的论点更安全,因为它是一个契约,实体可以改变为任何形式,并且DTO将保持不变.例如,类似于实体具有字段名称,并且DTO也具有字段名称.稍后,如果需求更改,数据库表发生更改,实体也可以更改,将名称更改为firstName和lastName.但是DTO仍然会有一个字段名,即firstName + lastName.

所以这里是使用DTO的优点列表:

1. 从接受DTO的代码的角度向后兼容

我能想到的DTO的缺点是:

1. 必须定义DTO类和映射(可能使用推土机)
2. 程序员必须分析何时使用DTO和实体,我的意思是为每个方法传递DTO都是一团糟
3. 将实体转换为DTO的开销,反之亦然
4. 我仍然不确定如何映射它们的一对多关系.在JPA中我们可以懒惰地初始化它,但是当传入DTO时,我应该初始化这个与否.很快,DTO不能使用惰性初始化代理,只包含值.

请分享你的想法..

谢谢 !

以下是来自不同地方的一些报价

亲:

将实体类重用为DTO似乎很麻烦.该类的公共API(包括公共方法的注释)不再明确定义它所呈现的合同的目的.该类最终将使用仅在将类用作DTO时才相关的方法,以及仅在将类用作实体时才相关的一些方法.关注点不会完全分开,事情会更紧密地结合在一起.对我而言,这是一个更重要的设计考虑因素,然后尝试节省创建的类文件的数量.

亲实体:

绝对不!!!

JPA实体映射到数据库,但它们不与数据库"绑定".如果数据库发生更改,则更改映射,而不是对象.对象保持不变.这就是重点!

Answer 1

我会选择DTO选项,原因如下:

• 服务接口应该独立于数据库,一个中的更改不应总是需要在另一个中进行更改.
• 您假设您的服务将始终由Java客户端调用
• 当对象位于Web服务调用的其他位置时使用延迟加载不能很好地工作.