Hibernate, a pesar de sus ventajas, era bastante aparatoso. Todos estos ficheros XML de mapping, los DAO, la realización de DAO...Se te quitan hasta las ganas de escribir código. En la última parte hemos creado un proyecto con Hibernate y hemos visto todo el jaleo q se lleva Hibernate.
Los creadores de Hibernate tb se han dado cuenta de lo aparatoso q era y han venido con una idea fantástica: para que crear los ficheros especiales de mapping elos DAO, donde "mapeamos" nuestra BD (y básicamente duplicamos la información sobre nuestra BD), si podemos simplemente escribir los nombres de las columnas encima los campos en los ficheros de entity:
La información que estaba en DAO y los ficheros Mapping viene metida cómodamente en los ficheros "entity" en forma de las anotaciones:
El tiempo pasaba y JDBC, con lo simple que era, tenía sus desventajas:
- El cambio de la BD? De Oracle a SQL Server ?
Venga - a parar el servidor, recompilar todo el proyecto y reiniciar el servidor. A un banco de parar su servidor de la producción por, digamos, una media hora, puede ser un problema....
- Fiabilidad
Si haces un pequeño programa para tu universidad o una pequeña empresa - no lo vas a notar. Pero que pasa, si tu aplicacion Java va ser ejecutada por miles de usuarios cada segundo? Imagina que 2 usuarios quieren a la vez actualizar la misma línea de BD, quien gana?
Por este motivo varios chavales han empezado a crear unas herramientas que se llamaban ORM (Object-Relational Mapping), donde las tablas y las relaciones entre las tablas en la BD están "mapeadas" en el código Java a traverso de los ficheros mapping XML (y mas tarde con el código Java usando las anotaciones). Al mismo tiempo la manera, en que una aplicación Java guarda los datos en una BD ha tambien evolucionado y así apareció la capa de Persistance, donde los datos primero estaban guardados en los objetos simples de Java (POJO) que tenían los setters y getters y luego una sesión les guardaba en la base de datos a traverso de una transacción.
Los primeros eran los de JBoss que han creado Hibernate en 2001. En verdad hay un montón de frameworks ORM - IBATIS, EclipseLink y no solo en Java, pero tb en C#, PHP, etc. Pero Hibernate sigue siendo una de mas simples y mas populares.
Hoy vamos modificar nuestro proyecto que hemos creado un la parte 1 y en vez de utilizar la conexión a traverso de un driver JDBC, utilizamos Hibernate. Voy pegar otra vez la esquema de la BD:
Aquí en vez de abrir y cerrar la conexión manualmente, utilizamos una sesión Hibernate que actualiza las tablas a traverso de un mapping XML. El mapping XML refleja le estructura de una tabla SQL en un file XML.
Stream API en Java8 se utiliza para trabajar con las colecciones, escribiendo el código en el estilo funcional.
Gracias a su simplicidad se ha hecho muy popular entre los programadores. Segun la descripcion oficial, la bilioteca «Java.util.stream» - nos permite hacer varias operaciones de estilo funcional con las colecciones de elementos, tales como transformaciones mapReduce, etc. Contiene las operaciones "intermedias", como Stream.map o Stream.filter, pero también las operaciones "finales" como Stream.forEach o Stream.reduce . Las operaciones "intermedias" no serán ejecutadas hasta q una operacion "final" sera llamada (Stream.map no sera ejecutado hasta Stream.reduce, tb si lo metes antes en el código). Ese comportamiento se llama LAZY.
Otra gran característica de Stream API es la paralelización de las fuentes parallelStream (). Se utiliza para mejorar el rendimiento cuando tienes q procesar grandes cantidades de datos. Las corrientes paralelas pueden acelerar la ejecución para ciertos tipos de transacciones. Yo las uso, cuando sé que la colección es demasiado grande para manejarla con «ForkJoin». Más información sobre la biblioteca ForkJoin puedes leer aqui: http://www.baeldung.com/java-fork-join.
Volvemos a nuestras ovejas y vamos a considerar un ejemplo práctico.
Un ejemplo para buscar máximos y mínimos en una colección.
Casi todos los tutoriales que he visto en internet te hacen crear el servicio y el cliente juntos en una aplicación. Pero dime cuando lo has visto en la vida real? En una empresa normal las aplicaciones y la infraestructura de back-end están claramente separados de los de front-end. Osea q las 2 cosas casi nunca van juntas. Los clientes front-end normalmente desarrollan programadores JavaScript juntos con diseñadores Web que a veces no están ni en el mismo edificio con los de back-end.
Por eso vamos a crear el servicio y el cliente por separado:
Servicio:
Paso 1:
Abre Eclipse y crea New->Dynamic Web Project o mejor con maven (New->Maven Project). Selecciona el arquetipo maven-archetype-webapp:
Lo llamamos app-test-greeting-service y va tener una estructura siguiente:
Paso 2:
Dentro src crea un paquete hello y tres classes Java:
La clase Application será una cosa mas tonta del mundo:
package hello;
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
@SpringBootApplication
public class Application {
public static void main(String[] args) {
SpringApplication.run(Application.class, args);
}
}
Luego creamos nuestra clase de entidad para los mensajes que tendrán una id y un contenido:
package hello;
public class Greeting {
private final long id;
private final String content;
public Greeting(long id, String content) {
this.id = id;
this.content = content;
}
public long getId() {
return id;
}
public String getContent() {
return content;
}
}
Bueno, y nuestro controlador REST de toda la vida:
package hello;
import java.util.concurrent.atomic.AtomicLong;
import org.springframework.stereotype.Controller;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RequestParam;
import org.springframework.web.bind.annotation.ResponseBody;
import org.springframework.web.bind.annotation.CrossOrigin;
import org.springframework.web.bind.annotation.RestController;
@RestController
public class GreetingController {
private static final String template = "Hello, %s!";
private final AtomicLong counter = new AtomicLong();
@RequestMapping("/greeting")
public Greeting greeting(@RequestParam(required=false, defaultValue="World") String name) {
return new Greeting(counter.incrementAndGet(), String.format(template, name));
}
}
- Ponle @RestController y no solamente @Controller, sino no va funcionar
- el counter va aumentar cada vez que clicas en "actualizar" de tu navegador web.
- el mensaje "Greeting" de la vuelta sera en formato JSON con el nombre que tu pasas como el parámetro (@RequestParam)
El pom de tu proyecto será pequeño:
Lanzalo clicando derecho en tu proyecto y seleccionando "Run As->Java Application" y vas a ver lo siguiente:
Cliente:
Paso 1:
- En el Eclipse haz copiar y pegar de tu proyecto anterior y cambiale el nombre a app-test-greeting-client.
- Puedes eliminar todo el código Java del proyecto anterior de src/main
Paso 2:
- Crea una carpeta public para meter tu pagina web con el código Angular/HTML dentro:
- Creamos nuestra pagina web index.html que nos va mostrar el mensaje:
Hello AngularJS
Your name:
The ID is {{greeting.id}}
The content is {{greeting.content}}
Si aun no sabes que es AngularJS, te explico rapidito que es lo que esta escrito:
- La pagina web de arriba es para Angular una aplicación (ng-app)
- Los bloques de la pagina que envían o reciben algo son controladores (ng-controller)
- Dale al controlador un nombre que asi lo puedes referenciar en el código Angular (ng-controller="Hello")
- Los campos para meter cosas son modeles(ng-model) y saben actualizarse (update()) cuando le das "click" (ng-click="update()") o presionas "enter" (ng-click="enter()")
- Los campos para recibir cosas se maraca con {{}}
- Crea un file hello.js y pega este codigo:
- La función $http.get viene ejecutado cada vez que visitamos nuestra pagina index.html
- Esta función va a la dirección (http://localhost:8080/greeting?name=Juan) y así enviando al servidor el parámetro name
- La vuelta el servidor (el mensaje Greeting en la forma JSON) metemos en una variable greeting ($scope.greeting = data)
- La pagina web HTML de arriba recibe esta variable y extracta 2 parámetros: id y content
The ID is {{greeting.id}}
The content is {{greeting.content}}
Clicamos varias veces en el botón y veremos como aumenta nuestro id.
En la segunda parte haremos una aplicación mas complicada que va obtenir información desde la base datos.
Sabemos que el lanzamiento de una aplicacion Spring Boot as muy fácil y se hace con el método main():
@SpringBootApplication
public class RestServiceDemoApplication {
public static void main(String[] args) throws Exception
{
SpringApplication.run(TuNuevaAplicacion.class, args);
}
}
Para probar rapidito, si tu aplicación va bien - eso es mejor método: lanzas y la Spring Boot se te lanza una instancia de Tomcat automáticamente. Pero q pasa, si lo tienes q desplegarla en otro servidor? Spring Boot te genera un JAR, pero otro servidor acepta solo un WAR para las aplicaciones web. Q hacemos?
Convertir JAR de Spring Boot en WAR es muy facil y asi lo puedes copiar y meter en la carpeta /webapps del servidor.
- Paso 1: tienes que añadir a tu clase principal la extensión de la clase SpringBootServletInitializer
@SpringBootApplication
public class RestServiceDemoApplication extends SpringBootServletInitializer
- Paso 2: tienes que añadir una implementación de un método de la clase SpringBootServletInitializer
ahora puedes crear el package o desde Eclipse, o desde la linea de comandos:
- mvn package
Maven te dira, donde el WAR sera creado: normalmente hay una carpeta target en la carpeta de tu proyecto.
Toma este WAR para desplegarlo en tu servidor:
La problemática de comunicación entre las aplicaciones Java y las bases de datos ha sido actual desde el primer año de la existencia del lenguaje Java. Hoy vamos a mirar, cómo con años ha evolucionado el método de esta comunicación haciendo una aplicación "enterprise" simple.
Principio
Tenemos una empresa que tiene unos empleadores (tabla Employee). Cadauno tiene su dirección (tabla Address). Y cadauno tiene sus proyectos en cuyos está trabajando (tabla Projects). Visto que cada proyecto puede tener varios empleadores y cada empleador puede trabajar en varios proyectos - tenemos una relación del tipo ManyToMany y eso lógicamente nos hace crear una tabla intermedia - una tabla con asociaciones entre empleadores y proyectos - la llamamos EmplProj:
EmployeeID ProjectID
1 1
1 2
2 2
3 3
4 4
Se ve que el empleador #1 trabaja con los proyectos #1 y #2, al mismo tiempo con el proyecto #2 están trabajando el empleador #1 y el empleador #2.
El esquema relacional de nuestra base de datos:
