问题是将 Jpa 实体的业务验证逻辑放在哪里更好(或者换句话说:您更喜欢在哪里)。
两个想法是:
- 在 EntityListener 中,在保存或更新之前将验证实体
- 在提供对 jpa 持久化方法的访问的服务中。
两者各有利弊。 当使用方法 2 时,它更容易测试,因为您可以模拟 jpa 提供程序并测试验证逻辑。另一方面,对于方法 1,验证将与 @NotNull 等验证同时发生。
我很想知道你们如何解决项目中的验证问题,哪种方法更好。
谢谢。
最佳答案
这是我遵循的一般经验法则:
When using bean validation, specify rules that do not require dependencies on other beans. The moment you depend on another bean, get your service layer to handle that dependency.
换句话说,如果您在另一个 bean 中引用了一个 bean,请避免放入 @NotNull 约束。您的服务层最适合用于此目的,因为您可以更早地在更合乎逻辑的点捕获违规(因为其他业务验证会假定 bean 可用)。
例如,考虑以下实体(抱歉无法编译)
@Entity
public class User
{
@Id
private int id;
@NotNull
private String fullName;
@NotNull
private String email;
private Set<Role> roles; //No bean validation constraints here.
...
public boolean mapRoleToUser(Role role)
{ //Validation is done here. Including checks for a null role.
}
}
@Entity
public class Role
{
@Id
private int id;
@NotNull
private String name;
}
在这种情况下,服务层应该验证用户是否附加了角色。 pre-persist 或 pre-update 阶段的验证有点太晚了,尤其是当有一个具有业务逻辑的不同服务层,以及领域模型中的其余业务逻辑时(遗憾的是,我还没有看到仅域模型中的所有逻辑就足够好的应用程序了)。
关于java - 验证 Jpa 实体 : In service or by lifecycle listeners,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/3370670/