DTO和实体在一个对象中? [英] DTO and Entity in one object?

问题描述

我目前处于两难境地，我一直在阅读有关此的东西.

I am currently in a dilemma and I've been reading stuff regarding this.

我使我的DTO也是我的实体.看起来像这样:

I am making my DTOs be also my Entities. It looks something like this:

@Entity
@PasswordMatches // custom validator
public class User {

    @Id
    @Column
    @GeneratedValue(strategy=GenerationType.IDENTITY)
    private Long id;

    @Column
    @NotNullOrEmpty // custom validator
    private String password;

    @Transient
    @NotNullOrEmpty // custom validator
    private String confirmPassword;

问题1 :这是可以接受的，还是有更好的方法呢?因为当前，在保存User之前，我出于明显的原因对哈希进行哈希处理，但是如果直接输入em.persist(user)，由于@PasswordMatches失败，它将失败.仅当我执行user.setConfirmPassword(hashedPassword)只是为了满足验证时，它才省下来.我在这里做正确的事吗?

Q1: Is this acceptable or is there any better way of doing this? Because currently, before saving a User I am hashing the password for obvious reasons but if I em.persist(user) directly, it will fail because of @PasswordMatches is failing. It's only saving when I do user.setConfirmPassword(hashedPassword) just to satisfy the validation. Am I doing the right thing here?

推荐答案

虽然EJB3允许将实体用作DTO，但事实是，最好有单独的DTO.

While EJB3 allowed for the possibility of Entities being used as DTOs, the truth is it is still better to have separate DTOs.

很快，您会发现您的实体将需要与特定JPA提供程序(如Hibernate)相关的注释，这些注释会将您的实体绑定到持久层.这意味着如果您的实体向上"传递到表示层，则该层需要知道"您在持久层中使用的特定库/框架.如果您正在从事网络工作，那不是什么大问题，但是如果您正在从事富客户(例如Swing)，那么这可能是客户需要随身携带的额外行李.

Pretty soon you will find that your Entities will require annotations related to specific JPA Providers (like Hibernate) which will tie your Entities to the persistence layer. This will mean that if your Entities are passed 'up' to your presentation layer, then that layer needs to 'know' about the specific libraries/frameworks that you are using in your persistence layer. That's not much of a problem if you are doing web stuff, but if you are doing rich clients (e.g. Swing) then that can be extra baggage that your clients need to carry around.

类似地，您将要开始为表示层注释实体(例如，使用@Json注释).将它们放在您的实体中将再次将您的持久性层与您的表示层联系起来.

Similarly, you will want to start annotating your Entities for the presentation layer (e.g. using @Json annotations). Putting these in your entities will again tie your persistence layer to your presentation layer.

最初，我们陷入了使用实体将数据传递给富客户端的陷阱，但是到意识到需要将它们分为DTO和持久性实体时，我们已经创建了300多个Entity类.与如此多的实体一起执行此操作是一次痛苦的经历，但是现在(拥有400多个实体类)，我们很高兴能够做到这一点.

Initially we fell into the trap of using our Entities to pass data up to our rich clients, but we had created over 300 Entity classes by the time we realised we needed to separate them into DTOs and persistence Entities. It was a painful experience to do that with so many Entities, but now (with over 400 Entity classes) we are glad we did it.

因此，尽管可以做您正在做的事情，但是您已经遇到了一个问题，其中将业务逻辑与持久层混合在一起会导致问题.我建议您将它们分为DTO和实体，以免将来出现继续的问题.

So, while it is acceptable to do what you are doing, you have already run into an issue where mixing business logic with your persistence layer has caused a problem. I would recommend you separate these out into DTOs and Entities to save you continued problems in the future.

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