JPA 实体和/与 DTO

在这些情况下帮助决定何时使用 DTO 以及何时使用 Entity 的总体思路是什么？

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 不能有延迟初始化的代理，只能包含值。

请分享你的想法..

谢谢 ！

以下是一些不同地方的引用

pro dto http://mdshannan1.blogspot.com/2010/10/reuse-jpa-entities-as-dto.html :

将实体类重用为 DTO 看起来很乱。的公共 API 类（包括公共注释 方法）不再明确定义 合同的目的是 呈现。该课程将结束于 仅在以下情况下才相关的方法 该类被用作 DTO 并且 有些方法只会 使用类时相关 作为一个实体。担忧将不会 干净地分开，事情就会 耦合更紧密。对我来说这是一个 更重要的设计考虑 然后尝试节省数量 创建的类文件。

专业实体 http://www.coderanch.com/t/462706/java-Architect-SCEA/certification/Pass-JPA-entities-across-tiers :

绝对不！！！

JPA 实体映射到数据库， 但它们并不“绑定”到数据库。 如果数据库改变，你就改变 映射，而不是对象。这 物体保持不变。这就是 重点！

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

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