JPA 实体和/与 DTO [英] JPA Entities and/vs DTOs

问题描述

在这些情况下帮助决定何时使用 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 不能有延迟初始化的代理，只能包含值.

请分享您的想法..

谢谢！

这里有一些来自不同地方的引用

pro dto:><块引用>

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

专业实体 :

<块引用>

绝对不会！！！

JPA 实体映射到数据库，但它们并没有绑定"到数据库.如果数据库改变，你改变映射，而不是对象.这对象保持不变.那就是整点！

解决方案

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

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

What is the general idea to help deciding when to use DTO and when to use Entity in these cases ?

1. UI / server side java calling the services. Should it get / send entities or DTOs ?
2. Web service calling the services. Should the services accept entities or DTOs ?

I like reading the code that pass entities around :

1. simpler to pass around, no need to map to DTOs
2. dont need extra classes
3. relations to other entities are already defined, so dont need combine related DTOs into one DTO
4. just POJOs

But there are arguments about DTO that maps to an entity is safer, because it's a contract, and the entity can change to whatever form, and the DTO will stay the same. For example, like the entity has a field name, and the DTO also has a field name. Later on, if the requirement changes, the database table changes, the entity can change also, changing name into firstName and lastName. But the DTO will still have a field name, which is firstName + lastName.

So here's the list of the pros of using DTOs :

1. backward compatible from the viewpoint of the code that accepts the DTOs

The cons of DTO i can think of is :

1. have to define the DTO classes and the mapping (perhaps using dozer)
2. the programmers would have to analyze when to use DTO and entity, i mean passing DTO for every methods is a mess
3. overhead of conversion of entities to DTOs and vice versa
4. I'm still unsure about the one-to-many relationship on how to map them. In JPA we can lazy initialize this, but when passing in DTO, should i initialize this or not. Shortly, DTOs cant have lazy initialized proxies, only contains values.

Please share you thoughts ..

Thank you !

Here are some quotes from different places

pro dto :

Reuse of the entity class as a DTO seems messy. The public API of the class (including annotations on public methods) no longer clearly defines the purpose of the contract it is presenting. The class will end up with methods that are only relevant when the class is being used as a DTO and some methods that will only be relevant when the class is being used as an entity. Concerns will not be cleanly separated and things will be more tightly coupled. To me that is a more important design consideration then trying to save on the number of class files created.

pro entity :

Absolutely NOT!!!

JPA entities are mapped to a database, but they are not 'tied' to a database. If the database changes, you change the mappings, not the objects. The objects stay the same. That's the whole point!

解决方案

I would go for the DTO option for the following reasons:

• The service interface should be independant of the database, a change in one should not always require a change in the other.
• You are making an assumption that your services will always be called by a Java client
• Using lazy loading when the object is on the otherside of a web service call does not work well.

这篇关于JPA 实体和/与 DTO的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！