En varias ocasiones he visto sobre el tema de persistencia en java la discusión de si es mejor usar annotations o ficheros de configuración XML.
Mi primera opinión, sin pensar mucho más, es que era mejor los ficheros de configuración XML, sin lugar a dudas. ¿Por qué?. Pienso que los bean de java deben ser reutlizables de proyecto en proyecto, que la base de datos es un tema aparte cuyas tablas pueden cambiar de un proyecto a otro y no me gusta meter dependencias de jar raros en mis clases básicas del modelo de datos. Las annotations de persistencia necesitan esos jar para compilar. De alguna forma, pienso que estoy "casando" mis clase con una herramienta específica.
Sin embargo, ahora que me he metido a jugar un poco con hibernate más en serio y empiezo a comprender la filosofía de trabajo de estas herramientas de persistencia, empiezo a dudar si es mejor los ficheros XML.
Por un lado, estoy mal acostumbrado en los proyectos en los que trabajo. Alguien diseña la base de datos primero, o incluso nos la da el cliente ya hecha y tenemos que hacer código para tratar con esa base de datos. De proyecto en proyecto, aunque la temática es la misma, nos hacen cambios en las bases de datos. Por ello, nuestras aplicaciones pretenden tener su propio modelo de datos a base de java beans y tratan de aislarse lo más posible de los detalles de la base de datos. El patrón DAO se nos hace fundamental.
Pero veo que la forma de trabajo de Hibernate está pensada al revés. Tú te haces tu modelo de datos con java beans y te olvidas de la base de datos. Con annotations o con ficheros XML haces el mapeo de esos beans sobre la base de datos e Hibernate se encarga de crear todas las tablas. Y pensándolo de esta forma, en que lo principal son tus java beans y las tablas de base de datos son "secundarias", empiezo a ver ventajas en las annotations sobre los ficheos XML.
Si se hacen java beans y ficheros XML de mapeo separados, estamos hasta cierto punto violando el principio DRY (Don`t repeat yourself). Si tocamos los java beans, debemos acordarnos de tocar el XML correspondiente y al revés. Debemos tocar en dos sitios distintos si cambia el tipo de una columna, añadimos o borramos un atributo a un java bean, etc. Con annotations es más dificil el despiste. Si cambio un atributo, lo añado o lo borro, la annotation está justo al lado y es más difícil olvidarse de ella.
Además, si vamos a reutilizar nuestros beans en otros proyectos y vamos a seguir el mismo mecanismo de persistencia, dejando a Hibernate o la herramienta de turno crear las tablas de base de datos, no es tan malo llevarse los bean con sus annotations. De hecho, es más cómodo que llevarse los bean y además sus ficheros xml.
La única pega que le veo a esto es que las annotations en ocasiones se complican demasiado, quitando claridad a un código en principio simple (un java bean). Y como ejemplo, este trozo de código sacado de la documentación de Hibernate, donde sólo se empieza a declarar la clase Forest (si, fíjate al final, la última línea….)
@Entity @BatchSize(size=5) @org.hibernate.annotations.Entity( selectBeforeUpdate = true, dynamicInsert = true, dynamicUpdate = true, optimisticLock = OptimisticLockType.ALL, polymorphism = PolymorphismType.EXPLICIT) @Where(clause="1=1") @org.hibernate.annotations.Table(name="Forest", indexes = { @Index(name="idx", columnNames = { "name", "length" } ) } ) @Persister(impl=MyEntityPersister.class) public class Forest { ... }
Convención frente a configuración.
Aunque sin lugar a dudas, xml es infinítamente peor que las anotaciones. Quien diga que un xml es facil de escribir, es que es lo único que ha usado y conoce. Un simple ini o el formato yamel es igualmente utilizable pero pueden ser escritos por humanos.
Nosotros lo que hacemos es generar los Beans de Hibernate/JPA a partir del esquema de la BDD, por que seguimos partiendo de la base de datos, ya que no siempre podemos usar motores ORM y de igual forma preferimos controla el esquema explicitamente.
Y a estas alturas yo optaría por JPA, que para algunas cosas da menos problemas que Hibernate, aunque lo tengas por debajo! como al modificar un bean que no tienes que hacer el saveOrUpdate() y lo de los campos opcionales (que pueden ser null) al crear nuevas instancias… Y además nos permite usar TopLink, que no usa tantos .jar, si tenemos algun conflicto.
Respecto a Anotaciones vs XML, mi criterio es más simple y menos radical. Para mi una anotación es código, ya que hay que compilarlo, así que es como cualquier otro valor que pones «hardcoded» en tu código. Cambios en esos valores implican re-compilar y re-distribuir binarios, así que las cosas que se deciden en tiempo de compilación, en anotaciones, las que pueden cambiar en la distribución, en ficheros fuera del código para poderlas cambiar más fácil.
Al menos ahora podemos elegir entre una opción y otra, que ya es un avance 🙂
S!