There is nothing wrong with using your entities as your domain objects. You have to be aware of using entities that have been detached and whatnot, but that can be managed.
I would not artificially create work for yourself by forcing each entity to be mapped to another bean (or POJO). Sometimes it is necessary to wrap many entities (or values from entities) into a bean, but only do it if there is a good reason.
Maybe the confussion is due to the fact that the entity is just a POJO with the mappings info (in the code as annotations or in a separate configuration file). Works as a POJO as long as you want (you can create and modify objects; as long as you don't save them with a Session they won't be written in the DB).
Sometimes you might need to have the data in a bean that is not an Entity (mainly because that bean is managed by another framework and you do not want to mix things *1), then you only have to copy (by an specific constructor, by calling lots of set...(), whatever) that data from your bean to your Entity/POJO.
我认为没有理由像这样有两个并行的对象层次结构。我会拥有实体并放弃您所说的 POJO。无需映射。这是对 CPU 周期的浪费，但我看不到任何好处。
I see no reason for two parallel object hierarchies like this. I'd have entities and ditch what you're calling POJOs. No need for mapping. It's a waste of CPU cycles for no benefit that I can see.
I am currently working on a three-tired Java EE app with JPA serving the back end. I use a single java class to represent each table in the database(entity classes) And i use the same classes to do all the operations, both in the business layer as well as the database layer. And it makes sense too.
Because in all the three layers, you can create an instance of the same entity class independently.
PS - @Hay : Even when i started learning JPA, I was doing manipulations with two different sets of same classes as you :) I guess, this practice emerged becoz of EJB 2.1 which didn't have any annotations in them. So basically two different sets of classes are required where one has to be entirely dedicated as ENTITY CLASSES for DAO operations.
As JPA evolved, Annotations are brought into picture, which made our lives easy.. OLD HABBITS DIE HARD indeed ;)
由于有如此多的注释，使用该对象的客户端需要所有 jar 依赖项。我认为注释可以移动到 XML 文件，但这样注释的优势就会消失。
还有其他创造性的解决方案吗？
@Data
@Entity
@XmlRootElement(name="sport")
@Table(name = "db_sport")
@NamedQueries({
@NamedQuery(name = "Sport.findAll", query = "SELECT d FROM Sport d")})
public class Sport implements Serializable {
@Id
@GeneratedValue(strategy = GenerationType.AUTO)
@Basic(optional = false)
@Column(name = "sportId")
int sportId;
}
Annotations do have their downside, especially in multi-tiered Java EE applications.
In the example below, you have a simple POJO object (Domain object) which you want
the java REST clients to use
the REST server accepts this object as a parameter, and
to persist this object to a database.
I would think this is a common use-case.
With so many annotations the clients using this object needs all the jar dependencies. I suppose the annotations can be moved to an XML file, but then the annotation advantages are lost.
Are there any other creative solutions?
@Data
@Entity
@XmlRootElement(name="sport")
@Table(name = "db_sport")
@NamedQueries({
@NamedQuery(name = "Sport.findAll", query = "SELECT d FROM Sport d")})
public class Sport implements Serializable {
@Id
@GeneratedValue(strategy = GenerationType.AUTO)
@Basic(optional = false)
@Column(name = "sportId")
int sportId;
}
您可能需要使用另一组类来防止连锁反应。对于具有多个依赖项的 Web 服务，通常会出现这种情况。数据映射通常会增加程序的复杂性，如果没有正当理由就应该避免。
You may need to use another set of classes to prevent ripple effect. This is often the case with web services that have several dependencies. Data mapping in general adds to complexity of program and should be avoided without a valid reason.
Unless you can remember how relationships are marked in your code and
when they are populated by hibernate and when/where they are accessed
in the code I would suggest you to go with DTO approach.
However, if you are learning hibernate or going to use it in small project it may be easy for you to return the entity (or a collection of them) from your controller layer.
But I'm sure the more you do it the more you will find the need to
move to DTO or even JsonView. If you are not the one who is
building UI then you will realize it even sooner.
Speaking of DTO, my fav is ModelMapper. You can do conversion (simple and complex whatever you like) at controller layer. This way you will know what you are returning inside the DTO.
发布评论
评论（8）
使用实体作为域对象没有任何问题。您必须注意使用已分离的实体等，但可以对其进行管理。
我不会通过强制每个实体映射到另一个 bean（或 POJO）来人为地为自己创造工作。有时需要将许多实体（或实体中的值）包装到一个 bean 中，但只有在有充分理由的情况下才这样做。
There is nothing wrong with using your entities as your domain objects. You have to be aware of using entities that have been detached and whatnot, but that can be managed.
I would not artificially create work for yourself by forcing each entity to be mapped to another bean (or POJO). Sometimes it is necessary to wrap many entities (or values from entities) into a bean, but only do it if there is a good reason.
也许造成混淆的原因是实体只是一个带有映射信息的 POJO（在代码中作为注释或在单独的配置文件中）。只要您愿意，就可以作为 POJO 工作（您可以创建和修改对象；只要您不使用会话保存它们，它们就不会写入数据库中）。
有时您可能需要将数据存储在不是实体的 bean 中（主要是因为该 bean 由另一个框架管理，并且您不想混合内容*1），那么您只需复制（通过特定的构造函数，通过调用大量的 set...()，无论如何）将数据从您的 bean 传输到您的实体/POJO。
*1 我在这里想到的是 JSF。
Maybe the confussion is due to the fact that the entity is just a POJO with the mappings info (in the code as annotations or in a separate configuration file). Works as a POJO as long as you want (you can create and modify objects; as long as you don't save them with a Session they won't be written in the DB).
Sometimes you might need to have the data in a bean that is not an Entity (mainly because that bean is managed by another framework and you do not want to mix things *1), then you only have to copy (by an specific constructor, by calling lots of set...(), whatever) that data from your bean to your Entity/POJO.
*1 I am thinking of JSF here.
我认为没有理由像这样有两个并行的对象层次结构。我会拥有实体并放弃您所说的 POJO。无需映射。这是对 CPU 周期的浪费，但我看不到任何好处。
I see no reason for two parallel object hierarchies like this. I'd have entities and ditch what you're calling POJOs. No need for mapping. It's a waste of CPU cycles for no benefit that I can see.
我目前正在开发一个三轮 Java EE 应用程序，并使用 JPA 为后端提供服务。我使用单个 java 类来表示数据库中的每个表（实体类），并且我使用相同的类来执行所有操作，无论是在业务层还是在数据库层。这也有道理。
因为在所有三层中，您都可以独立创建同一实体类的实例。
PS - @Hay：即使当我开始学习 JPA 时，我也在使用两组不同的相同类进行操作:) 我想，这种做法是在 EJB 2.1 中出现的，因为 EJB 2.1 中没有任何注释。因此基本上需要两组不同的类，其中一组必须完全专用于 DAO 操作的实体类。
随着 JPA 的发展，注释被带入人们的视野，这让我们的生活变得轻松。.旧习惯确实很难消逝;)
I am currently working on a three-tired Java EE app with JPA serving the back end. I use a single java class to represent each table in the database(entity classes) And i use the same classes to do all the operations, both in the business layer as well as the database layer. And it makes sense too.
Because in all the three layers, you can create an instance of the same entity class independently.
PS - @Hay : Even when i started learning JPA, I was doing manipulations with two different sets of same classes as you :) I guess, this practice emerged becoz of EJB 2.1 which didn't have any annotations in them. So basically two different sets of classes are required where one has to be entirely dedicated as ENTITY CLASSES for DAO operations.
As JPA evolved, Annotations are brought into picture, which made our lives easy.. OLD HABBITS DIE HARD indeed ;)
注解确实有其缺点，尤其是在多层 Java EE 应用程序中。
在下面的示例中，您有一个简单的 POJO 对象（Domain 对象），您希望
我认为这是一个常见的用例。
由于有如此多的注释，使用该对象的客户端需要所有 jar 依赖项。我认为注释可以移动到 XML 文件，但这样注释的优势就会消失。
还有其他创造性的解决方案吗？
Annotations do have their downside, especially in multi-tiered Java EE applications.
In the example below, you have a simple POJO object (Domain object) which you want
I would think this is a common use-case.
With so many annotations the clients using this object needs all the jar dependencies. I suppose the annotations can be moved to an XML file, but then the annotation advantages are lost.
Are there any other creative solutions?
您可能需要使用另一组类来防止连锁反应。对于具有多个依赖项的 Web 服务，通常会出现这种情况。数据映射通常会增加程序的复杂性，如果没有正当理由就应该避免。
You may need to use another set of classes to prevent ripple effect. This is often the case with web services that have several dependencies. Data mapping in general adds to complexity of program and should be avoided without a valid reason.
我的 0.20 美元
但是，如果您正在学习 hibernate 或打算在小型项目中使用它，那么您可能很容易从控制器层返回实体（或其集合）。
说到 DTO，我最喜欢的是 ModelMapper。您可以在控制器层进行转换（无论您喜欢简单还是复杂）。这样您就会知道 DTO 内返回的内容。
My $0.20
However, if you are learning hibernate or going to use it in small project it may be easy for you to return the entity (or a collection of them) from your controller layer.
Speaking of DTO, my fav is ModelMapper. You can do conversion (simple and complex whatever you like) at controller layer. This way you will know what you are returning inside the DTO.
请参阅 JPA 最佳实践幻灯片="nofollow noreferrer">李竹穆恩。您可以在 JPA 最佳实践 - 印度 Java 播客。
See the slides of JPA Best Practices of Lee Chuk Munn. You can find it in JPA Best Practices - Indo Java Podcast.