Ofertas en tecnología

creando una clase DAO genérica

Altavoz inteligente Echo Dot

Tiempo atrás era común localizar la lógica de persistencia de datos adjuntado con las reglas de negocio. Esto aumentó sensiblemente la dificultad de comprender y sostener el emprendimiento. Transcurrido un tiempo, las técnicas de avance maduraron y brindaron sitio a ciertos patrones de diseño que se usan bastante hoy en día, como el patrón de diseño MVC (Modelo – Vista – Controlador). Este patrón de diseño divide la app en capas con responsabilidades concretas, de la próxima forma:

  • Modelo: solicitado de albergar la lógica de persistencia y conversión de datos de la SGDB en elementos de app, de manera genérica o no.
  • vista: propósito de albergar toda la información visual que tenga dentro entradas de datos, reglas de visualización, entre otros muchos.
  • controlador: responsable de utilizar las reglas de negocio de la app.

En el contexto previo, es viable cotejar el patrón de diseño DAO (objeto de ingreso a datos) con la cubierta Model del patrón MVC, en tanto que brotó de la necesidad de dividir la lógica de persistencia de la lógica empresarial de la app. Este estándar tiene como propósito canjear información de manera sin dependencia con el DBMS y proveer los conceptos básicos para efectuar CRUD o funcionalidades mucho más complicadas. En el momento en que se aplica adecuadamente, se abstrae toda la necesidad de buscar y registrar información, lo que provoca que el desarrollo de manipulación de datos de entidades sea transparente para las otras capas del sistema, o sea, una clase de Persona tiene la posibilidad de tener un DAO destinado a efectuar operaciones concretas en el sistema. DBMS, por servirnos de un ejemplo, consultando personas por CPF, edad, etcétera.

El inconveniente

Sabiendo que una clase X tiene la posibilidad de tener una representación XDAO encargada de realizar su lógica de persistencia, piensa si hay 100, 150, 1000 entidades que precisan integración con la banco de información. ¿Sería preciso hacer exactamente la misma proporción de clases DAO para realizar las reglas de persistencia de estas entidades?

La solución

Merced al término de Generics que se encuentra en Java, es viable hacer una clase DAO que va a ser con la capacidad de abstraer cualquier género de entidad de la app y realizar comandos concretos, descartando de esta manera los llamados repetitivos (código cliché). Así mismo, si un número N de entidades del sistema tienen especificaciones afines, en vez de hacer N clases DAO, cada una representando un modelo, la app tendría solo una clase genérica abstrayendo la ocupación en común entre un conjunto concreto de elementos que precisan estar comunicado con la banco de información.

Nota: Para reducir el ahínco de hacer consultas de banco de información y acrecentar la eficacia de este producto, se usará la biblioteca JPA (API de persistencia de Java), que abstrae los métodos CRUD de una forma fácil y entendible.

Elementos precisos

  1. IDE de su decisión
  2. JAR de la biblioteca JPA, implementación de Hibernate
  3. Servidor MYSQL 5
  4. JAR del conector MYSQL

composición del articulo

  1. Creación del emprendimiento de ejemplo y configuración de la biblioteca JPA
  2. Hacer la clase de conexión de la banco de información
  3. Creación de las clases modelo
  4. Creación de clases DAO genéricas
  5. Probando la clase DAO genérica

1. Creación del emprendimiento de ejemplo y configuración de la biblioteca JPA

Cree un emprendimiento Java y después cree el directorio META-INF en la carpeta raíz. Esta carpeta va a ser la responsable de alojar el fichero de configuración JPA, el persistencia.xml.

Antes de hacer este fichero, descargue los JAR de Hibernate con JPA y el conector MYSQL. Una vez descargados, agréguelos a la ruta de colección del emprendimiento.

O persistencia.xml es el responsable de determinar los factores de desempeño de la JPA y debe contener información como: nombre de la unidad de persistencia, cadena de conexión con la banco de información, usuario, contraseña, nombre del banco, controlador de conexión, entre otros muchos. Como el propósito de este producto no es escudriñar este fichero, ahora se expone la plantilla básica para llenar este tutorial.



 
 
 org.hibernate.ejb.HibernatePersistence
 
 
 
 
 
 
 
 
 
 
 
 
 
 

2. Creando la clase de conexión a la banco de información

En este momento cree la clase que se ocupará de entablar la conexión con la banco de información usada por el sistema.

package br.com.raphaelneves.connection;

import javax.persistence.EntityManager;
import javax.persistence.EntityManagerFactory;
import javax.persistence.Persistence;

public class ConnectionFactory 

Como es un recurso caro para la app, el atributo de factoría se empleará con el modificador estático de no ingreso, esto es, este atributo va a ser único para cada instancia de la clase ConnectionFactory producida. De esta manera, la factoría unicamente se va a crear la primera oportunidad que se utilice la clase ConnectionFactory.

3. Creación de clases modelo

Las clases modelo indican la representación de entidades que precisan integración con la banco de información. Para esto, cree una plataforma de trabajo que estipule el procedimiento getId(). Este procedimiento se ocupará de devolver la clave principal de las entidades “clientes del servicio”, que a su juicio es de tipo Long. El diseño EntidadeBase va a ser el contrato de las entidades de la app que precisen emplear los elementos del SGBD, o sea, todas las entidades que trabajen con persistencia de datos van a deber “firmar” este contrato.

public interfaz EntidadeBase

A sabiendas de que las entidades del modelo van a tener firmado el contrato BaseEntity, es viable vincular la especificación de la clase DAO genérica a fin de que admita toda clase de entidad que implemente esta plataforma de trabajo y cumpla con los requisitos de IS-A BaseEntity. Cree 2 clases, Person y Car, aplicando el diseño BaseEntity y especifique los atributos y hábitos de la próxima forma:

package br.com.raphaelneves.pojo;

import javax.persistence.Column;
import javax.persistence.Entity;
import javax.persistence.GeneratedValue;
import javax.persistence.GenerationType;
import javax.persistence.Id;
import javax.persistence.Table;

@Entity
@Table(name="tb_pessoa")
public class Pessoa implements EntidadeBase 
package br.com.raphaelneves.pojo;

import javax.persistence.Column;
import javax.persistence.Entity;
import javax.persistence.GeneratedValue;
import javax.persistence.GenerationType;
import javax.persistence.Id;
import javax.persistence.Table;

@Entity
@Table(name="tb_carro")
public class Carro implements EntidadeBase 

Las notas @Entity, @Table, @Column, @Id, @GeneratedValue son elementos proporcionados por JPA para detallar que una cierta clase se identifique como una clase modelo para la manipulación de datos con el DBMS. En expresiones mucho más crudas, estas notas hacen que la clase represente una entidad, tabla o columna en la banco de información.

4. Creación de la clase DAO genérica

En este momento que la app puede producir una conexión de banco de información y mapear las entidades del modelo, cree una clase llamada DaoGenerico. Este tipo va a ser la responsable de agrupar la lógica de persistencia común entre el conjunto de entidades del contrato EntidadeBase. Este producto cubrirá los métodos para añadir, cambiar, buscar por clave primordial y remover un registro en la banco de información, el popular CRUD.

public class DaoGenerico 

Esta declaración de clase deja producir una instancia de DaoGenerico que represente a cualquier entidad que estable el contrato BaseEntity (T prolonga BaseEntity). Entonces defina un atributo de gestor, de tipo EntityManager y con modificador estático sin ingreso. Este atributo dejará la utilización de métodos JPA.

Para hacer más simple y facilitar la entendimiento, el ciclo vital de EntityManager no va a ser gestionado.

public class DaoGenerico 

Un corto ejemplo de de qué forma instanciar un elemento DaoGeneric que representa la entidad Persona.

DaoGenerico daoPessoa = new DaoGenerico();

JPA tiene un procedimiento con la capacidad de efectuar la búsqueda dependiendo del género de entidad del modelo y su clave primordial, en un caso así el atributo ID de las clases del modelo. La sintaxis de este procedimiento es:

manager.find(Entidade.class, chavePrimaria);

Cree el procedimiento de búsqueda, findById, recibiendo como factor el género de entidad del modelo esperado y su ID. Además de esto, se definirá como devolución una entidad de tipo T. Nótese que T es la entidad modelo que contrató los servicios de BaseEntity.

public class DaoGenerico 

Los métodos de registro y edición tienen un accionar muy afín, guardando algo en la banco de información. Por consiguiente, es viable revisar si el razonamiento del procedimiento tiene un ID nulo o no. Si la verificación es verídica, la entidad se guardará; en caso contrario, se actualizará.

Para esto se va a crear el procedimiento saveOrUpdate sin retorno, puesto que la meta de momento es solo insertar/actualizar el registro en la banco de información, y va a recibir como factor una entidad de tipo T. Imaginemos que la entidad modelo tiene múltiples otras entidades que persisten en una cascada. Para asegurar la integridad de los datos en el banco, se va a aplicar el término de transacción. Así, si hay un fallo en el desarrollo de persistencia en cascada, se retrotraerá todo el desarrollo implicado en este contexto.

public class DaoGenerico 

El procedimiento de exclusión va a funcionar un tanto diferente a el resto, puesto que es requisito efectuar una búsqueda de la entidad que se suprimirá y solo entonces hacerla desaparecer. Lamentablemente, este es un bucle establecido por nuestro procedimiento remove() de JPA. El procedimiento remove de la clase genérica no va a devolver y va a recibir como factor el género de clase modelo y su clave principal, en un caso así el ID. Entonces, se activará el procedimiento de búsqueda que está desarrollado y va a devolver la entidad que se suprimirá.

public class DaoGenerico 

5. Prueba de la clase DAO genérica

Para pruebe las funcionalidades de persistencia genérica cree las clases InsertApplication, UpdateApplication, FindByIdApplication y RemoveApplication, todas las que representa una ocupación CRUD en la implementación del procedimiento main().

public class InsertApplication 

Captura de pantalla en 11-36-28

Captura de pantalla en 11-37-31 Captura de pantalla en 11-37-21

public class FindByIdApplication 

Captura de pantalla en 11-45-09

public class UpdateApplication 

Captura de pantalla en 11-46-57

public class RemoveApplication 

Puede bajar el código fuente de este producto desde mi GitHub.

¡Hasta la próxima!

Producto anunciado inicialmente en el Blog Raphael Neves

Tommy Banks
Estaremos encantados de escuchar lo que piensas

Deje una respuesta

TecnoBreak | Ofertas y Reviews
Logo
Enable registration in settings - general
Shopping cart