JPA实体和/与DTO

Question

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

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

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

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

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

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

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

我能想到的DTO的缺点是：

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

请分享你的想法..

谢谢！

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

pro dto：

  

将实体类重用为DTO   看起来很乱。公共API的   class（包括公共注释）   方法）不再明确定义   合同的目的是什么   呈现。课程结束了   只有在相关的方法   该课程被用作DTO和   一些方法只会   在使用课程时相关   作为一个实体。关注不会   干净利落地分开，事情就会如此   更加紧密耦合。对我而言，这是一个   更重要的设计考虑因素   然后试图节省数量   创建了类文件。

pro entity：

  

绝对不是!!!

     

JPA实体映射到数据库，   但他们并没有“绑定”到数据库。   如果数据库发生更改，则更改   映射，而不是对象。该   对象保持不变。那就是   全点！

Answer 1

我会选择DTO选项，原因如下：

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

Answer 2

Pro DTO： 1. UI大多数时候都需要某些属性，这些属性仅用于传递描述UI状态的参数。该状态不需要保持，因此不需要在实体上使用 2.业务逻辑应该在实体内部，或者在entite的辅助类中。您不应与UI / Presentation Layer或客户端调用它共享它 3.实体的变化有时不需要改变DTO，反之亦然。
4.更容易在UI服务中对DTO执行系统级验证，因此在不应该停止对业务服务的调用时。
5.当UI端接收DTO而不是填充来自UI的数据的实体时，您可以自由地实现/使用其他验证框架。
6. UI /表示层松散耦合。

以下是使用DTO时的示例流程：
UI - ＆gt; MVC - ＆gt;使用UI服务的系统验证 - ＆gt;业务代表 - ＆gt;商业服务 - ＆gt;持续。