Creando reglas de entidades

Question

Me gustaría saber la respuesta a esta simple pregunta.

Cuando creo un objeto de entidad y quiero restringir la configuración de un atributo (por ejemplo, no deseo permitir que nadie establezca un valor entero menor que 1 a un atributo), ¿debería implementarlo en el setter de este atributo o debería verificar esta restricción en una clase que maneja estos objetos? En general, ¿puedo implementar getters y setters como quiera siempre que mis getters regresen y setters establezcan atributos?

Sé que hay algunas reglas (convenciones de código) en Java, por lo que no quiero romper ninguna de ellas.

Gracias de antemano, espero que mi pregunta sea lo suficientemente clara y lo siento por cualquier error de gramática que haya cometido: /.

Answer 1

Sí getters/setters son útiles para eso.

por ejemplo:

public void setAge(int age){ 
if(age < 0){ 
    throw new IllegalArgumentException("Invalid age : " + age); 
    //or if you don't want to throw an exception you can handle it otherways too 
} 
} 

También puede utilizar Java-EE de Bean Validators para este

public class Person{ 

    @Min(value = 0) 
    @Max(value = 99) 
    private Integer age; 

    //some other code 
} 

Answer 2

Este es el objetivo de getters y setters.

Si no podemos agregar un comportamiento en estos métodos, bueno ... ¿por qué no utilizamos atributos públicos?

Answer 3

Desde mi entendimiento de su pregunta, es más o menos relacionada con el principio de encapsulación OO. Puede echar un vistazo a este artículo: http://www.tutorialspoint.com/java/java_encapsulation.htm

Answer 4

Mi método preferido es usar JSR 303 (Bean Validation API) para asegurar que las propiedades de la clase son válidos.

Está bastante bien para realizar la validación en setters, pero esto no siempre es un enfoque deseable. Existe el potencial de mezclar las necesidades de varios contextos que no están relacionados entre sí. Por ejemplo, algunas de sus propiedades nunca deben configurarse desde la interfaz del usuario, sino que un servicio las calculará antes de que se conserven. En tal caso, no es deseable tener esta lógica dentro de un setter, ya que necesitaría conocer el contexto en el que se invoca al setter; necesitarás aplicar diferentes reglas en tu capa de interfaz de usuario y en tu capa de persistencia. JSR 303 le permite separar estas preocupaciones usando grupos de validación, para que su grupo de validación UI sea diferente de su grupo de validación de persistencia.

En JPA 2.0, cuando Anote en su clase mediante limitaciones que son evaluados por un validador de JSR 303, el proveedor de persistencia puede evaluar automáticamente estas limitaciones en el PrePersist, PreUpdate y PreRemove (por lo general no se realiza, véase más adelante) eventos del ciclo de vida de entidades. Para realizar la validación de entidades en su proveedor de JPA, debe especificar el elemento validation-mode o la propiedad javax.persistence.validation.mode en su archivo persistence.xml; los valores deben ser AUTO (valor predeterminado) o CALLBACK (y no NONE).

La presencia de un proveedor de Validación de frijoles es suficiente para garantizar que la validación se produce en los eventos del ciclo de vida de la entidad JPA, ya que el valor predeterminado es AUTO. Obtienes esto por defecto, en un servidor de aplicaciones Java EE 6; Glassfish utiliza la implementación de RI de JSR 303, que es Hibernate Validator, y también funciona bastante bien con EclipseLink.

El modo CALLBACK le permitirá anular los grupos de validación que se aplicarán cuando se desencadenen los eventos del ciclo de vida. De forma predeterminada, el grupo de validación de Bean predeterminado (Default) se validará para los eventos de actualización y persistencia; el evento de eliminación no implica ninguna validación. El modo CALLBACK le permite especificar un grupo de validación diferente para estos eventos, utilizando las propiedades javax.persistence.validation.group.pre-persist, javax.persistence.validation.group.pre-update y javax.persistence.validation.group.pre-remove.

Tenga en cuenta que la validación de JSR 303 se puede utilizar fuera de un contenedor Java EE, aunque el enlace de la documentación de la API Bean Validation que publiqué anteriormente es de la documentación de la API de Java EE 6.

Answer 5

Los buscadores y colocadores son geniales para agregar restricciones, al igual que Jigar Joshi tiene en su respuesta. De esta forma, obtienes comentarios de inmediato y puedes manejar el problema cuando se presenta.

Otra solución sería usar la validación de objetos (algo así como una implementación JSR-303) que le permitiría anotar el campo con valores mínimos y máximos. Algo así como

@Min(value=1) 
private int myvalue; 

A continuación, puede validar el objeto completo de una sola vez y obtener todos los mensajes si tiene otros campos limitados. Obviamente, esto no es útil en todas partes, pero si se ajusta a tus necesidades, es una opción.

Finalmente, cuando dice "entidad", pienso en algo almacenado en una base de datos o relacionado con herramientas ORM. Si ese es el caso, querrás tener cuidado con lo que haces en tu getter. Por ejemplo, si realiza una inicialización diferida en el getter, algunos proveedores de ORM marcarán la entidad como sucia e intentarán vaciarla a la base de datos, lo que posiblemente cause una escritura involuntaria.