2011-06-08 11 views
19

No entiendo por qué JSR 303 (validación de bean) es para los métodos getter y no setter? ¿No es más lógico ponerlo bajo el método setter ya que ese es el punto de entrada a un campo y la validación debe ser verificada antes de eso?JSF: JSR 303 Validación de frijoles: ¿por qué en getter y no en setter?

+2

No entiendo por qué está poniendo la restricción en un getter en lugar del campo en sí. ¿No es más lógico ponerlo en el campo mismo, ya que es, bueno, el único campo en sí? – BalusC

+0

@BalusC Yeap! Estoy de acuerdo contigo. Entonces, la pregunta es si realizo la validación en ese campo, ¿también necesito poner una anotación en ese método getter de campo? Si no, ¿por qué hay una anotación para el método getter? – yapkm01

Respuesta

5

Es una muy buena pregunta y algo que nunca he prestado atención. Pero creo que sé la respuesta (y también por qué nunca me hice esta pregunta).

Si está viendo esto, desde el punto de vista de que, la anotación define dónde ocurrirá la validación, entonces ponerlo en getter no tiene sentido. (¿por qué no validar mientras se almacena el valor en sí mismo ...). Pero esta no es la forma en que funciona ...

El programador necesita contarle al marco de validación qué propiedades deben validarse. Entonces puedes poner la anotación directamente en el atributo (que yo prefiero) o puedes ponerlo en el getter. Ambos significan operación de lectura. El Framework necesita leer todos los atributos de su clase, que deberán ser validados. Entonces, en este caso, poner setter no tiene ningún sentido ... La clave para entender es la perspectiva ...

Espero que tenga sentido.

+0

Sí, no tendrá sentido si lo miras de esa manera.No creo que el posicionamiento de su anotación en getter, realice la validación en getter. Simplemente estamos marcando ese atributo como algo que el marco necesita validar. –

+0

entiendo lo que estás tratando de decir. Por lo que entiendo con respecto al ciclo de vida de JSF, si hay un error de validación durante la fase de validación del proceso, se vuelve a mostrar la misma página. ¿No debería invocarse un método setter para hacer la validación? Un método getter solo se invoca en una fase de renderizado de página. ¿Por qué validar en una fase de renderizado de página? La forma en que lo veo, no tiene sentido hacer la validación en esta fase, ya que ... bueno, todo está bien ahora y, por lo tanto, dicha página se representa para su visualización. – yapkm01

+0

Es porque hay casos en los que no hay un método setter. El colocador no se incluiría, por ejemplo, en una propiedad de solo lectura. – ialexander

19

Anotar getters no significa que la validación se realiza cuando se invoca un getter. Solo se usa para identificar la propiedad a la que se aplicará una restricción.

La gran ventaja de poner restricciones en los captadores (generalmente públicos) en lugar de los campos (generalmente privados) es que las restricciones son parte de la API pública del tipo de esa manera. Incluso se agregarán al JavaDoc generado. Un usuario de un tipo sabe de qué manera se aplican restricciones sin tener en cuenta su implementación interna.

Otra ventaja de anotar getters es que las restricciones se pueden poner en métodos en clases base o interfaces y también se aplican a cualquier subtipo/implementación.

+0

Si ese es el caso, no veo ningún problema si las restricciones se ponen en el método de establecimiento público. Mismo resultado según su respuesta – yapkm01

+7

Creo que una ventaja del uso de métodos getter en lugar de setter es que esto permite tener propiedades inmutables para las cuales no existe ningún setter al obtener las ventajas del nivel de propiedad (opuesto al nivel de campo) como se describió anteriormente. – Gunnar

+0

@ yapkm01 por favor, eche un vistazo a mi respuesta. Hay un problema con el método setter. No siempre se puede predecir el campo correcto usando el método de establecimiento público. –

5

consideran este código:

public class BeanValidation { 

    private int nameSetCount = 0; 
    private int nameGetCount = 0; 
    private String name; 

    public String getName() { 
     this.nameGetCount++; 
     return name; 
    } 

    public void setName(String name) { 
     this.nameSetCount++; 
     this.name = name; 
    } 

} 

Put anotación sobre private String name;

anotación identifica campo fácilmente con sólo mirar el campo.

anotación puesto sobre public String getName()

anotación identifica campo fácilmente con sólo mirar la regresaron campo.

Put anotación sobre public void setName(String name)

anotación no puede identificar campo mirando el campo modificado porque no puede haber más de uno.

+3

reflexión no mira la implementación del método, mira el nombre del getter/setter y lo compara con un campo –

Cuestiones relacionadas