Java Persistence

Han escuchado o trabajado con JPA?...., pues es el momento Java Persistence nos hace una invitación, "ESTANTARIZAR LA FORMA QUE TRABAJOS CON EL MAPEO DE DATOS OBJETO RELACIONAL", JPA (Java Persistence Api) es la api definida por Sun como el nuevo estandar
para la administración y desarrollo de aplicaciones que accedan a bases de datos relacionales, (caracteristica que son bastante comunes en las aplicaciones que encontramos hoy en dia), pero que ofrece JPA para desarrollar aplicaciones flexibles, rapidas y faciles de construir?....,

esa fue una pregunta que me formule al momento de comenzar a investigar sobre el tema, y encontre por medio de mucha lectura y practica varias respuestas que me gustaria compartirlas con cualquiera que se haya tomado un par de minutos en leer esta entrada del blog

1. Al ser un estandar debe de ofrecer una forma estandar de realizar las tareas comunes que realizan los diferentes proveedores de persistencia como Hibernate o TopLink, para ello se ha desarrollado una forma facil y elegante que permite que JPA pueda ser utilizado no solo por aplicaciones J2EE sino tambien por J2SE, esta forma es por medio del uso de Anotaciones, las cuales son una caracteristica nueva a partir de la versión 5.0 de Java.
2. Independicia de proveedor de Persistencia y de Fuente de datos subyacente, lo que permite desarrollar sistemas que acceden a bases de datos de cualquier tipo de proveedor, llamese Oracle, Postgres, MySQL, DB2, SQL Server....., elige la que mas te guste.
3. Completamente integrado con EJB 3.0 (puesto que hacen parte de la misma JSR), lo que permite integrar facilmente la capa de negocio con la capa de persistencia
4. Permite por medio de anotaciones definir las posibles relaciones existentes entre entidades como por ejemplo uno a uno (OneToOne), Uno a Muchos (OneToMany) Muchos a Uno (ManyToOne) y Muchos a Muchos (ManyToMany), me gusta mucho el hecho de que cuando se crean relaciones de ManyToMany automaticamente en la Base de datos se crea la entidad que relaciona a las 2 entidades (o tablas si se prefiere utilizar este termino en lugar de entidad) que es tambien llamada entidad o tabla dependiente
5. Si el modelo relacional ya esta creado en la base de datos, JPA tambien soporta el mapeo en sentido inverso, lo que quiere decir que lo que son tablas en la base de datos automaticamente pueden convertirse en entidades que se relacionan directamente con las tablas existentes en la Base de datos.
6. Pocas lineas de codigo tanto para crear las entidades como para acceder y realizar operaciones sobre ellas.
7. Uso de EntityManager y de un PersistenceContext para llevar a cabo todas las operaciones de inserción (persist) actualizacion (merge) y borrado (remove)
8. Uso de JPQL (Java Persistente Query Lenguaje) el cual es un lenguaje algo similar a SQL ansi, sin embargo con algunas cuantas diferencias, es bastante robusto y permite realizar consultas sobre las entidades (las cuales no hay que olvidar que solamente son objetos planos de Java POJO's) y dichas entidades se sincronizan automaticamente con la Base de datos y las tablas que hacen referencia las entidades.
9. Se permite de una forma muy clara y simple definir las politicas de creación de tablas en la Base de datos, a partir de las entidades, supongamos que tenemos una aplicación que desplegamos varias veces, cada vez que se despliega una aplicación el contenedor EJB lee el archivo persistence.xml y con trata de crear las tablas en el DataSource especificado pero pueden darse 2 escenarios:
1. Las tablas ya existen debido a que anteriormente la aplicación ya ha sido desplegada
2. Las tablas no existen en la base de datos ya sea porque es la primera vez que se despliega la aplicación o porque han sido eliminadas anteriormente.

En cualquiera de los casos en el archivo persistence.xml se contempla la desicion que el contenedor EJB debera tomar, ya sea borrar las tablas y volverlas a crear con las entidades que se tienen en el archivo de despliegue o dejar las tablas y sus datos tal cual estan en la base de datos, aunque esto puede ser muy ventajoso tambien es muy riesgoso en entornos de produccion, Imaginate desplegar una aplicación de nomina con la desición de borrar y recrear, automaticamente se perderia la información que ha sido almacenada alli, es por esto que es mejor tener cuidado y saber cual es el mejor escenario de acuerdo al entorno en el que se esta desarrollando, un tip muy valido y que sin duda aplica, es el siguiente, Si se esta desarrollando en un entorno de DESARROLLO, no hay ningun problema si la estructura es borrada y recreada, puesto que supuestamente se trata de un entorno de pruebas, de hecho es mejor hacerlo asì, para no mantener basura en la BD, pero en el caso que se trate de un entorno de PRODUCCIÓN por nada de este mundo nos conviene BORRAR LOS DATOS!!!, son premisas que se deben tener en cuenta y es necesario preveer.

Si desean ver mas sobre JPA, les invito a ver las conferencias de Java One ON-LINE desde el sitio de Sun, eso si, se debe tener una cuenta en la comunidad de desarrolladores de Sun (SDN), la crean y ya, podran acceder a sus contenidos, con voz y video, esta en AQUI

Bueno un saludo a todos, y como siempre, mi correo esta abierto para las dudas que puedan tener, y que por supuesto yo pueda solucionar.

JDaanial.

[+/-] Continuar Leyendo...