Entidades Validando Jpa: En el servicio o por los oyentes del ciclo de vida

Question

La pregunta es dónde es mejor (o en otras palabras: ¿Dónde prefiere) para poner la lógica de validación del negocio de entidades JPA.

dos ideas son:

1. En el EntityListener que antes de guardar o actualizar validaría la entidad
2. En el servicio que proporciona acceso a los métodos persistentes de la APP.

hay pros y los contras de ambos. Al utilizar el enfoque n.º 2, es más fácil realizar la prueba, ya que es posible que se burle del proveedor de jpa y pruebe la lógica de validación. Por otro lado, con el enfoque n. ° 1 la validación ocurriría en el mismo momento con validaciones como @NotNull, etc.

Me encantaría saber cómo se resuelven las validaciones en sus proyectos y cuál es la mejor forma de hacerlo.

Gracias.

Answer 1

He aquí una regla del pulgar general de que sigo:

Cuando se utiliza la validación de frijol, especifique reglas que no requieren dependencias en otros granos. En el momento en que dependa de en otro bean, obtenga su capa de servicio para manejar esa dependencia.

En otras palabras, si tiene una referencia a un bean dentro de otra, evite poner esa restricción @NotNull. La capa de servicio se usa mejor para eso, ya que está detectando la violación mucho antes, y en un punto más lógico (ya que otras validaciones comerciales supondrían que los beans están disponibles).

Como ejemplo, considere la siguiente entidad (disculpas por lo puedo compilar)

@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; 
} 

La capa de servicio, en este caso, es el que debe validar si el usuario tiene un papel adjunta o no. La verificación en la fase de pre-persistencia o pre-actualización es un poco tarde, especialmente cuando hay una capa de servicio distinta que tiene lógica de negocios, y el resto de la lógica de negocios en el modelo de dominio (lamentablemente, no he visto una aplicación lo suficientemente buena con toda la lógica en el modelo de dominio solo).