Anotacions sobre Hibernate

1. Guía hacia Hibernate : http://www.javahispano.org/contenidos/es/guia_del_autoestopista_a_hibernate_/

¿Que es Hibernate?

Hibernate ofrece la Persistencia Relacional para Java, que para los no iniciados, proporciona unas muy buenas maneras para la persistencia de sus objetos de Java a y desde una base de datos subyacente. Más que ensuciar con SQL tus objetos y convertir consultas a y desde los objetos de primera magnitud, Hibernate puede preocuparse de todo ese maremágnum por ti. Tú utilizas solamente a los objetos, Hibernate se preocupa del SQL y de que las cosas terminan en la tabla correcta.

El Proceso Del Desarrollo.

Hay varias maneras de acercarse al desarrollo con Hibernate. Aquí está el que estamos utilizando nosotros hoy, porque es probablemente el más simple de entender:

1. Crea tu tabla del SQL para guardar tus objetos persistentes.
2. Crea un JavaBean que represente ese objeto en código.
3. Crea un archivo de mapeo de manera que Hibernate sepa qué características del bean se mapean a que campos del SQL.
4. Crea un archivo de propiedades de manera que Hibernate conozca la configuración JDBC para acceder a la base de datos.
5. Comienza a usar el Hibernate API.

Paso 1: Escribir el SQL

** En el meu cas he procedit al disseny de la base de dades de forma manual, i després el PHPMYADMIN ha procedit a la creació de les corresponents taules.

**Les taules a tractar són les següents : Grup, Pertany, Usuari, Esdeveniment

**Per el cas dels usuaris, tot i que s'ha d'aplicar a tota la resta

Cuando tenemos un montón de Users en memoria, necesitaremos una clase Java para que los contenga. Hibernate trabaja vía reflection en los métodos de get/set de los objetos, así que necesitaremos "bean"-ificar los objetos que deseamos persistir.

** Per tant necessitem un Usuari.java amb les funcions de get/set per a cada paràmetre de la taula d'usuaris.

Paso 3: Escribir el archivo de Mapeo

Ahora ya hemos conseguido nuestra tabla del SQL, y el objeto de Java que va a mapearse con ella. Todavía necesitamos una manera de decir a Hibernate cómo mapear uno con otro. Esto se logra a través de un archivo de mapeo. La manera más limpia (la más mantenible) es escribir un archivo de mapeo por objeto.

** Exemple del tros d'arxiu de mapeig (el propi de la meva taula d'usuris):

Etiqueta class. Aquí mapeamos el nombre de la clase (en el paquete del *usuari*) a la tabla de usuarios en nuestra base de datos.

Etiquetas property. Un vistazo rápido mostrará que aquí es donde se está haciendo el trabajo importante. El atributo name es la característica en nuestro Bean, y column es el nombre del campo en nuestra base de datos. El atributo type es opcional (Hibernate utilizará reflection para conjeturar el tipo si tu no lo pones).

**Només he ficat una de totes les possibles.

etiqueta id. Quizás hayas sospechado que esta etiqueta tiene algo que ver con el mapeo de la clave primaria de la tabla. Tienes razón. La sintaxis de la etiqueta id es muy similar a la de las etiquetas de características que acabamos de ver. Mapeamos la característica del Bean (name) al campo de la base de datos(column). La etiqueta embebida del generador le dice a Hibernate cómo debe producir la clave primaria (es bastante divertido que Hibernate te genere una, del tipo prefieras, pero necesitaras decirle cómo).

Paso 4: Crear un archivo con las características para su base de datos

< style="font-family:verdana;">
< package="edu.upc.pfc.eci.negoci">
< name="Usuari" table="usuari">
< name="Id" type="string" column="userid">
< class="sequence">
< /generator>

< name="Userlogin" column="userlogin" type="string" null="true" length="255">

< /property>
< /id>
< /class>
< /hibernate-mapping>

Todavía no le hemos dicho a Hibernate dónde encontrar nuestra base de datos. La manera más directa es proporcionar a Hibernate un fichero de las características, con los ajustes para las secuencias de la conexión, las contraseñas, etc. Si llamas a este archivo hibernate.properties y lo pones en el classpath, Hibernate lo tomará automagicamente (sic). El fichero tendría un aspecto como este:

       hibernate.connection.driver_class = org.gjt.mm.mysql.Driver
   hibernate.connection.url = jdbc:mysql://localhost/testdb
   hibernate.connection.username = gsmith
   hibernate.connection.password = sesame

Si has utilizado JDBC, éste te resultara familiar. En el ejemplo de arriba un driver de mysql, se conecta con la base de datos testdb en localhost, y utiliza el usuario y contraseña proporcionados. Hay un montón más de características que puedes ajustar para determinar cómo Hibernate tiene acceso a tu base de datos. De nuevo, consulta la documentación para más información detallada.

Paso 5: Comience a hacer magia con Hibernate

Hacer uso de Hibernate en tu código fuente es bastante directo. Ahí va la versión reducida:

1. Cree un objeto Datastore

2. Dile al Datastore el tipo de objetos que deseas almacenar

3. Crea una sesión a la base de datos de tu elección

4. Carga, guarda y consulta tus objetos

5. flush() tu sesión de vuelta a la base de datos

Primero, creamos el objeto de Datastore...

El objeto Datastore tiene conocimiento de todos los mapeos que existen entre los objetos de Java y la base de datos.

        Datastore ds = Hibernate.createDatastore();
    ds.storeClass(User.class);

Esto asume que tienes un User.hbm.xml en el mismo directorio que la clase user. Si decides llamar a tu archivo de otra manera, utiliza:

 ds.storeFile("MyMappingFile.hbm.xml")

Entonces, crea un objeto de sesión...

El objeto de sesión representa una conexión a su base de datos. Puedes proporcionar a Hibernate una sesión de JDBC que hayas creado a mano, pero soy perezoso, así que solo voy a proporcionarle a Hibernate el archivo de propiedades, y dejar que haga el trabajo por mí.

        // Then build a session to the database
    SessionFactory sf = ds.buildSessionFactory();
    // or supply a Properties arg
    Session session = sf.openSession();

He llamado a mi archivo de propiedades hibernate.properties y lo he puesto en mi classpath, pero si has llamado al tuyo de manera diferente (o quieres crear las propiedades en el código), entonces necesitaras proporcionar tu propio objeto de propiedades a buildSessionFactory().

¡Después carga, guarda y consulta tus objetos!...

Ahora solo tienes que usar los objetos de una manera Java. ¿Quieres almacenar un nuevo usuario en la base de datos? Seria algo así:

 // Create new User and store them the database 
    User newUser = new User();
    newUser.setID("joe_cool");
    newUser.setUserName("Joseph Cool");
    newUser.setPassword("abc123");
    newUser.setEmailAddress("joe@cool.com");
    newUser.setLastLogon(new Date());

    // And the Hibernate call which stores it
    session.save(newUser);

Como puedes ver, la gran ventaja de Hibernate es el poco código adicional a emplear. La mayor parte del tiempo solo te preocupas de tus objetos de negocio, y haces una sola llamada a Hibernate cuando todo esta preparado.

Pongamos por caso que deseas recuperar un objeto y sabes el UserID del usuario (ej. durante un proceso de la conexión a su sitio). Con una unica línea, pasando la clave ya lo tienes :

    newUser = (User) session.load(User.class, "joe_cool");

El objeto usuario que has recuperado esta vivo! Cambia sus propiedades y se guardara en la base de datos en el próximo flush().

Incluso mejor , puedes consultar tu tabla y obtener una java.util.List de objetos vivos. Prueba con algo como esto:

List myUsers = session.find("from user in class dbdemo.User");

if (myUsers.size() > 0) {
for (Iterator i = myUsers.iterator(); i.hasNext() ; ) {
  User nextUser = (User) i.next();
  System.out.println("Resetting pass: "+ nextUser.getUserName());
  nextUser.setPassword("secret");
}
}else {
System.out.println("Didn't find any matching users..");
}

Esta consulta devuelve toda la tabla . Normalmente querrás mucho mas control (ej. From user in class dbdemo.User where userID tenga algún valor especifico),de manera que harás algo como esto:

        List myUsers = session.find("from user in class dbdemo.User where user.ID = ?","joe_cool", Hibernate.STRING);

Hay una gran abundancia de opción de consulta en la documentación, pero esto te da una idea de lo que Hibernate puede ofrecerte.

...Y finalmente flush() tu session

De vez en cuando tu sesión de Hibernate se hará flush() a si misma para mantener una correcta sincronización entre la BD y tus objetos en Memoria. Puedes querer liberar la conexión JDBC que Hibernate esta usando para lo cual normalmente harás:

        // close our session and release resources
    session.flush();
    session.close();

** tot això amb el plugin per eclipse està molt simplificat :D

Arquitectura técnica per a aplicacions mòbils

A l'hora de definir el projecte cal tenir en compte l'arquitectura, ja que d'ella pot dependre l'èxit del nostre projecte.

Per a les aplicacions destinades als dispositius mòbils disposem de sis tipologies / estils d'arquitectura: Thick Client, Rich Client, Streaming, Thin Client, Messaging, No Client.

Per tal de poder decidir quina aplicar a la midlet, primer de tot procediré a fer una breu explicació de cadascuna d'elles:

1. Thick Client:
Tenim que tant les dades com el codi es troba emmagatzemat al dispositiu, això implica que l'aplicació s'ha d'encarregar de la gestió de l'espai de memòria.

Avantatges: Funciona independentment de si el dispositiu disposa de cobertura o no. A més, ens permet treballar amb perifèrics i l'aplicació de estratègies de seguretat.

Restriccions: És complex de desenvolupar, de testejar i de mantenir. El fet de treballar de forma desconnectada augmenta la complexitat ja que podem tenir conflictes a l'hora d'actualitzar la informació, tot hi que això ho haurem de solucionar amb les polítiques de reescriptura.

S'aconsella aplicar aquesta arquitectura quan l'aplicació requereix càlculs sofisticats, quan els requeriments de l'aplicació no depenen de la latència de la xarxa, però sobretot quan es requereix treballar amb perifèrics.

Per tant, en el cas de la nostra midlet potser no seria interessant aplicar aquest tipus d'arquitectura ja que està basada per a la utilització de perifèrics que nosaltres no requerim.

2. Rich Client
En aquest cas, el codi continua guardant-se al dispositiu però les dades no tenen per què ser guardades.

Avantatges: El cost de realització és més baix que el Thick Client, també millora el cost de la gestió i de les operacions. Aquesta arquitectura té el potencial per ser la més potent i la més difícil de dissenyar. El codi local suporta estratègies de seguretat pròpies.

Restriccions: Les operacions fora de línea només estan disponibles si l'aplicació no requereix accés a les dades en temps real. És millor aplicar aquesta arquitectura en un rang limitat de tipus de dispositius. Tecnologies com J2ME pateixen variacions substancials d'un dispositiu a un altre, fet que fa incrementar el cost i la complexitat.

S'aconsella utilitzar aquesta arquitectura quan es requereixen tractaments en local, com pot ser la validació d'unes dades. També s'aconsella per a quan l'aplicació no requereix accedir a les dades del servidor en temps real.

3. Streaming
Aquest tipus d'arquitectura es reserva per aplicacions que requereixin "objectes multimèdia". No és una arquitectura gaire utilitzada per les corporacions. La seguretat de les dades depèn de factors externs a l'aplicació, com poden ser els drets digitals de gestió o les xarxes virtuals privades.

Avantatges: És una arquitectura que esta optimitzada per l'enviament de àudio i vídeo a un ampli públic.
Restriccions: Requereix un gran ample de banda, que las xarxes tinguin baixa latència i un processador bastant potent. El cost pot ser significant si la xarxa a de carregar grans paquets de dades.

S'opta per aquesta arquitectura quan necessitem treballar amb àudio i vídeo.

4. Thin Client
Les aplicacions que empren aquesta arquitectura utilitzen un client genèric pre-instal·lat per fer l'aplicació i l’ intèrpret del codi. No tenim dades guardades en el dispositiu excepte les cookies.

Avantatges: Encara es redueix més el TCO (Typical Total Cost of Ownership), perquè ara no tenim ni codi ni dades en el dispositiu. La informació està centralitzada i s'accedeix a ella a través d'un explorador web.

Restriccions: Aquest tipus d'arquitectura requereix d'una bona cobertura de xarxa i amb una baixa latència. El dispositiu ha de tenir pre-instal·lat un explorador o un client flash (no és habitual trobar clients flash en els telèfons mòbils). La utilitat de l'aplicació es inferior que els clients thick o rich. A més tot hi que cada vegada els exploradors estan més estandaritzats pateixen importants variacions en funció dels dispositiu en el qual s'utilitzin.

Es recomana recórrer a aquesta arquitectura quan tenim garantida una bona cobertura. Quan les aplicacions són simples i apropiades per ser executades en un explorador, i les condicions de seguretat són satisfetes mitjançant HTTPS.

5. Messaging
Les aplicacions que treballen sota aquesta arquitectura utilitzen el mail, SMS o IM per enviar informació al dispositiu client. L'usuari pot respondre mitjançant un missatge.

Avantatges: La simplicitat. És una arquitectura que es basa en tecnologia que ja està feta com pot ser el e-mail mòbil i els missatges curts. A més és pot aplicar a qualsevol telèfon mòbil.
Restriccions:És una arquitectura poc útil, donat que l'usuari ha d'indicar les accions amb els missatges SMS. A més no tenim la garantia de que arribin sempre els missatges enviats.

Es recomana aquesta arquitectura quan necessitem realitzar simples transaccions o notificacions. Cal tenir en compte que hi ha un elevat nombre de dispositius clientes no suportats.

6. No client
Consisteix en una arquitectura limitada per aquelles transaccions on el to de trucada o el reconeixement de veus interactives és un model d'interacció vàlid.

No és el que estem buscant per aplicar al projecte.

Un cop analitzades totes les possibilitats i coneixent els requeriments de l’aplicació client penso que la millor opció seria la Rich Client basada en J2ME entre altres raons perquè:

· és la que esta pensada per a tecnologies de la plataforma Java, per tant requerim d’aquesta tecnologia ja que la midlet és una aplicació J2ME.

· La tecnologia J2ME ens permet accedir a les dades de l’usuari del dispositiu mòbil, ja que són les que conté la seva agenda amb les que volem treballar.

· No té exigències amb la cobertura ni la latència de la xarxa.

· Se’ns permet treballar sense cobertura, que és el que ens interessa, ja que només la necessitarem quan requerim dur a terme la sincronització de dades, no necessitem accedir a aquestes en temps real.

· No ens genera la necessitat de tenir un dispositiu mòbil especialment potent ni amb gran quantitat d’espai lliure a la memòria ja que en aquesta guardarem només les dades de configuració necessàries per a que l’aplicació funcioni, un exemple d’aquestes són URL del servidor, username, password d’accés, ... és a dir dades amb poc pes espaial.