JPA陷阱/错误

根据我在帮助团队和进行培训方面的经验，这是我遇到的一些陷阱/错误，这些陷阱/错误在使用JPA的基于Java的系统中引起了一些问题。

• 需要一个公共的无参数构造函数
• 始终使用双向关联/关系
• 使用@OneToMany收集可能庞大的集合

需要一个公共的无参数构造函数

是的，JPA @Entity需要零参数（或默认的无参数）构造函数。 但这可以得到protected 。 您不必将其public 。 这样就可以实现更好的面向对象的建模，因为您不必强制使用可公开访问的零参数构造函数。

实体类必须具有no-arg构造函数。 实体类也可以具有其他构造函数。 no-arg构造函数必须是public 或protected 。 [强调我的]

–摘自Java Persistence API 2.1规范（Oracle）的2.1节

如果要建模的实体在创建时有一些字段需要初始化，则应通过其构造函数来完成。

注意：一些JPA提供程序可以通过在构建时添加一个无参数的构造函数来克服缺失的无参数构造函数。

假设我们正在建模酒店房间预订系统。 在其中，我们可能有诸如房间，预订等之类的实体。预订实体可能需要开始日期和结束日期，因为没有停留时间来创建一个预订实体就没有多大意义。 在保留的构造函数中将开始日期和结束日期作为参数包括在内，将可以提供更好的模型。 保留受保护的零参数构造函数会使JPA满意。

@Entity
public class Reservation { ...
 public Reservation(
   RoomType roomType, DateRange startAndEndDates) {
  if (roomType == null || startAndEndDates == null) {
   throw new IllegalArgumentException(...);
  } ...
 }
 ...
 protected Reservation() { /* as required by ORM/JPA */ }
}

注意： Hibernate（JPA提供程序）允许将零参数构造函数设为私有。 这使您的JPA代码不可移植到其他JPA提供程序。

它还有助于在零参数构造函数中添加注释，以指示它是出于JPA目的（技术基础结构）而添加的，并且不是域所必需的（业务规则/逻辑）。

尽管我在JPA 2.1规范中找不到它，但可嵌入类也需要一个默认（无参数）构造函数。 就像实体一样，可以将必需的无参数构造函数设为protected 。

@Embeddable
public class DateRange { ...
 public DateRange(Date start, Date end) {
  if (start == null || end == null) {
   throw new IllegalArgumentException(...);
  }
  if (start.after(end)) {
   throw new IllegalArgumentException(...);
  } ...
 }
 ...
 protected DateRange() { /* as required by ORM/JPA */ }
}

DDD示例项目还通过使它成为包范围来隐藏no-arg构造函数（请参阅Cargo实体类，其中no-arg构造函数位于底部附近）。

始终使用双向关联/关系

JPA上的教学材料通常显示出双向关联。 但这不是必需的。 例如，假设我们有一个包含一个或多个项目的订单实体。

@Entity
public class Order {
 @Id private Long id;
 @OneToMany private List<OrderItem> items;
 ...
}

@Entity
public class OrderItem {
 @Id private Long id;
 @ManyToOne private Order order;
 ...
}

很高兴知道JPA支持双向关联。 但是实际上，这成为维护的噩梦。 如果订单项不必知道其父订单对象，则单向关联就足够了（如下所示）。 ORM只需要知道如何命名多边表中的外键列。 这是通过在关联的一侧添加@JoinColumn批注来提供的。

@Entity
public class Order {
 @Id Long id;
 @OneToMany
 @JoinColumn(name="order_id", ...)
 private List<OrderItem> items;
 ...
}

@Entity
public class OrderItem {
 @Id private Long id;
 // @ManyToOne private Order order;
 ...
}

由于OrderItem不再需要保留对Order实体的引用，因此使其变得单向变得更容易。

请注意，有时可能需要双向关联。 实际上，这种情况很少见。

这是另一个例子。 假设您有几个引用某个国家/地区实体的实体（例如，人的出生地，邮政地址等）。 显然，这些实体将引用国家实体。 但是，国家是否必须引用所有这些不同的实体？ 很有可能，不是。

@Entity
public class Person {
 @Id Long id;
 @ManyToOne private Country countryOfBirth;
 ...
}

@Entity
public class PostalAddress {
 @Id private Long id;
 @ManyToOne private Country country;
 ...
}

@Entity
public class Country {
 @Id ...;
 // @OneToMany private List<Person> persons;
 // @OneToMany private List<PostalAddress> addresses;
}

所以，仅仅因为JPA支持双向关联， 并不意味着你必须！

使用

假设您正在建模银行帐户及其交易。 随着时间的流逝，一个帐户可以进行数千（甚至数百万）笔交易。

@Entity
public class Account {
 @Id Long id;
 @OneToMany
 @JoinColumn(name="account_id", ...)
 private List<AccountTransaction> transactions;
 ...
}

@Entity
public class AccountTransaction {
 @Id Long id;
 ...
}

对于只有少量交易的帐户，似乎没有任何问题。 但是随着时间的流逝，当一个帐户包含成千上万个（如果不是上百万个）交易时，您很可能会遇到内存不足的错误。 那么，有什么更好的映射方法呢？

如果不能确保关联的多面中的最大元素数都可以全部加载到内存中，则最好在@ManyToOne的另一侧使用@ManyToOne 。

@Entity
public class Account {
 @Id Long id;
 // @OneToMany private List<AccountTransaction> transactions;
 ...
}

@Entity
public class AccountTransaction {
 @Id Long id;
 @ManyToOne
 private Account account;
 ...
 public AccountTransaction(Account account, ...) {...}

 protected AccountTransaction() { /* as required by ORM/JPA */ }
}

要检索一个帐户可能数千（如果不是几百万）的交易，请使用支持分页的存储库。

@Transactional
public interface AccountTransactionRepository {
 Page<AccountTransaction> findByAccount(
  Long accountId, int offset, int pageSize);
 ...
}

要支持分页，请使用Query对象的setFirstResult(int)和setMaxResults(int)方法。

摘要

我希望这些说明可以帮助开发人员避免犯这些错误。 总结一下：

• 需要公众。 JPA要求的无参数构造函数可以设为public或protected 。 如果需要，可以考虑对其进行protected 。
• 一直使用 考虑单向而不是双向关联/关系。
• 使用 避免使用@OneToMany收集可能庞大的集合。 考虑@ManyToOne映射关联/关系的@ManyToOne端，并支持分页。

翻译自: https://www.javacodegeeks.com/2016/02/jpa-pitfalls-mistakes.html