java - 使JPA实体字段在REST环境中不可变

Question

Jersey REST Web 服务有两个简单的 JPA 实体。基本上，业务项目有一个创建者，指的是用户。序列化时不一定要向客户端显示业务项的创建者，所以有 JsonIgnore 注解。假设我允许每个用户通过 HTTP PUT 请求更新 BusinessItem 名称，但不允许更新创建者值。

@Entity
public class BusinessItem {
    @GeneratedValue(strategy = AUTO)
    @Id
    Long id;

    String name;

    @JsonIgnore
    @ManyToOne
    @JoinColumn(name = "creator_id", nullable = false, updatable = false)
    User creator;
} 

@Entity
public class User {
    @GeneratedValue(strategy = AUTO)
    @Id
    Long id;

    String name;

    @OneToMany(fetch = LAZY, mappedBy = "creator")
    List<PhotoSpot> createdPhotoSpots;
}

问题是，一旦从客户端收到带有 JSON 正文的 PUT 请求并反序列化，则创建者字段将为空。然后，为了更新数据库中的实体，我需要通过业务项 ID 从数据库检索创建者值，替换为反序列化实体，然后才将更新应用于数据库。这一切听起来都不优雅，而且是样板。

对于此类问题，什么是优雅的解决方案？

Answer 1

服务和实体之间的直接关联可以是非常简单的应用程序中的实用设计。然而在许多情况下这不是一个合适的选择。正确管理实体关系可能是进行更加结构化的设计的一个很好的理由。

在标准 MVC 应用程序的通常设计中，不直接使用实体作为 JavaBean 是一个很好的做法。通过 View/page 访问(该实体是 EJB 容器中的 Enterprise JavaBean，不要混淆)。实现TransferObject pattern是一种常见的解决方案(请注意，该链接中记录的序列用于数据检索操作，而不是更新)。 Controller 通常假定构建TransferObject。然后它变成 recommended candidate for a DAO operation .

REST 服务与 MVC 模式没有太大区别:事实上，这是一个 Entity-Control-Boundary pattern (在 Jersey <= 2 个应用程序的情况下，即使 this should evolve in Java EE 8 ，区别也可能非常微妙)。服务本身是一个边界，取代了 View 。

换句话说，根据核心 J2EE 模式，优雅的解决方案是向 TransferObject 提供 PUT 参数:然后将该对象传输到 DAO。然后，DAO 层只需从数据库中检索适当的托管实体即可获取实体关系并报告传输的值以更新到托管实体，同时保留关系(这可以通过 DAO 来完成)。

Java EE 设计可能非常具有挑战性。该平台提供与图案形状非常相似的开箱即用组件。但在某些情况下，这些并不能替代。例如，EntityManager 看起来像 DAO。但是使用显式 DAO 通常会提供清晰易懂的代码，而直接使用 EntityManager 可能会非常冗长，因为事务未封装。

结论

在您的情况下，对我来说重要的是使用 DAO 来封装您的数据库操作(只有当您确实需要映射关系时才这样做，否则 @Transient 注释将是一个办法)。无论如何，在执行merge(...)操作之前，您都必须检索托管实体。 TransferObject 的使用不是强制性的，这只是一个正确设计的建议。在许多情况下，这可能会导致冗长的代码。您有多种解决方案来限制此问题:一个简单的 Map可以限制代码，例如 BeanUtils 的实用程序也可以是珍贵的。

但是在建立 DAO 时避免基本的传输操作可能具有挑战性。在您的情况下，这将导致在 DAO 层中使用 MultivaluedMap，从依赖关系的角度来看，这似乎不是一个好主意，因为它链接了模型/实体和 View /边界组件。这可能就是核心 J2EE 模式引入 TransferObject 的原因。