Aunque hace tiempo que quería meterme con eso y hablar de la validación de campos/atributos lo he ido dejando... además tengo pendiente un post sobre las excepciones que algún día saldrá a la luz ;) Hoy voy a dar paso a hablar de una de las herramientas más usadas y conocidas para el chequeo de beans como es Hibernate Validator.
Hibernate Validator 4.x (a partir de ahora HV) es una implementación de la JSR-303 (Bean Validation) que tiene su principio básico de trabajo en ofrecer/facilitar el proceso de validación a cualquier nivel de la aplicación. Clásicamente esta validación de campos de las entidades del modelo se realiza en la capa de persistencia, básicamente, por evitar duplicación en las demás capas. También suele ser habitual que los formularios de una aplicación Web validen su contenido previo envío al servidor. La idea de HV siguiendo la JSR es evitar esa duplicación y proveer un proceso único de validación en la "capa" que se desee, desde persistencia hasta clientes ricos o Swing. El siguiente sería el gráfico explicativo, sacado de la documentación oficial:
La interpretación de la imagen sería que las reglas de validación están en el modelo del dominio y el proceso de validación es posible en cualquier parte de la aplicación. El proceso es bastante sencillo, se trata de anotaciones que se realizan en las entidades de negocio o de forma declarativa en un XML. Como suele ser habitual se proveen varias formas de definición de reglas de validación.
Así a modo de señalas los puntos más importantes fui tomando notas según iba investigando sobre HV. Aquí os pongo esos puntos porque explicar todo sería redundante con respecto a la documentación oficial y el #kinicast que pretendo hacer. Además los mega-post se me hacen pesados ;)

JSR 303

  • JSR 303 – defines a metadata model and API for entity validation.
  • The default metadata source is annotations, with the ability to override and extend the meta-data through the use of XML.
  • The API is not tied to a specific application tier or programming model.
  • It is specifically not tied to either the web tier or the persistence tier, and is available for both server-side application programming, as well as for rich client Swing application developers.

Hibernate Validator features

  • Defining validation data using annotation and/or XML.
  • Full object validation (including inner objects using recursion)
  • Create customized constraints and validators.
  • Customized error messages.
  • Define groups(profiles).
  • Create a Traversable Resolver.

Uso

  • Se suelen aplicar a nivel de campo, propiedades y clase.
  • Se pueden usar tanto anotaciones en los beans como declaración en XMLs.
  • Les podemos dar preferencia unos sobre otros de forma declarativa en el XML, independientemente del nivel al cuál las declaremos.
  • Para usarlo se cargan las validaciones y se invocan para un bean pudiendo iterar sobre las restricciones que viola con mensajes explicativos. Estos mensajes son fácilmente personalizables creando nuestros propios ficheros.
  • Si queremos hacerlo de forma declarativa por XML tenemos que cargar previamente el XML que contiene las validaciones.

Definir nuestras propias validaciones

  • Eso se divide en dos pasos: crear la interfaz para la anotación y la clase que validará el valor del campo concreto.
  • Debemos crear una interfaz que contendrá la restricción (Constrain). En ella hay cosas por defecto en toda restricción y luego la personalización.
  • También podemos “sobreescribir” restricciones ya existentes. Simplemente anotamos la interfaz que creemos con esa restricción previo la declaración de la interfaz (previo a public @interface ...).
  • Para realizar el proceso debemos crear la clase validadora que llevará a cabo la acción concreta apoyándose en la restricción y será quién finalmente diga si el valor que se le pase es válido o no.
  • Podemos crear anotaciones compuestas por varias ya definidas simplemente anotándolas en la definición de una nueva (como al “sobreescribir”). Esto reportará una violación por cada una pero se puede personalizar para que simplemente haga un único reporte.

Personalizar los mensajes
Hay varias formas:

  • La más sencilla (e intrusiva) es Indicar el mensaje directamente en el XML o en la anotación.
  • Usando un fichero de mensajes externo con el cuál se cargará la factory de validaciones para configurar cada una de las instancias. Existen dos formas, creando un fichero que busca HV por defecto en el classpath, o creando uno e indicárselo.
Grupos
  • Sirven para juntar validaciones y aplicarlas a la vez según la situación. Por ejemplo, si tenemos la entidad Persona podemos tener dos grupos de reglas "CreateValidations" y "UpdateValidations" las cuáles se aplicarán en el salvado o en el actualizado de una nueva entidad persona respectivamente.
Soy consciente que no explico demasiado en este post, pero solo pretendo dejar unas pinceladas para abrir boca, todos los puntos pretendo abarcarlos en (seguramente) varios vídeos :)
Recursos de donde he sacado la información