Persistencia de Java: Clave Primaria compleja con objeto
Como se vió, con el API de Persistencia de Java (Java Persistence API - JPA) se puede mapear todas las tablas de una base de datos como entidades para ser manipuladas desde objetos java.
Ahora, ¿qué pasa con entidades débiles?
Una entidad débil es aquella que depende su existencia de otra entidad. Por ejemplo, el detalle de una factura no puede existir sin una factura. Si se traslada este concepto a una base de datos, entonces, la clave primaria del detalle de factura será: la clave primaria de la factura a quien pertenece, y el número de orden que se muestra en la lista.
Mapear la entidad FACTURA es simple:
La entidad DETALLE_FACTURA tiene la clave primaria compuesta por dos campos: ID_FACTURA y NRO_ORDEN. En java, toda la clave primara es un objeto con el mismo nombre de la clase primaria más el sufijo "PK". Pero además, esta clave primaria debe tener una referencia a la misma factura de quien pertenece. Entonces, debemos crear la entidad primaria así:
Como se ve, solo va el atributo que se enlazará con la tabla, que debe ser del mismo tipo (a menos que especifique lo contrario).
Ahora, al mapear la entidad FACTURA_DETALLE, esta debería tener la clave primaria (PK) además, del objeto que hará referencia con su 'padre', es decir, con FACTURA:
Se podrá pensar "pero, no se estará haciendo redundancia?, porque ya en el PK ya está el objeto Factura. tengo que volverlo a declarar como atributo de FacturaDetalle". Pues sí, de otra manera el API no podrá saber cómo hacer referencia desde la entidad FACTURA_DETALLE con FACTURA.
"¿No se haría más pesado tener que programar que cada vez que agrego una detalle a la factura colocar en ambos atributos el valor de su cabecera?"
Bueno, sí, pero utilizando una buena implementación del patrón DAO, este se puede hacer cargo de él. Además, debería de hacer persistente a cada línea de detalle. Aquí un ejemplo:
Y el método agregarDetalle() sería así:
Ahora, ¿qué pasa con entidades débiles?
Una entidad débil es aquella que depende su existencia de otra entidad. Por ejemplo, el detalle de una factura no puede existir sin una factura. Si se traslada este concepto a una base de datos, entonces, la clave primaria del detalle de factura será: la clave primaria de la factura a quien pertenece, y el número de orden que se muestra en la lista.
Mapear la entidad FACTURA es simple:
@Entity
public class Factura implements Serializable {
@Id
@GeneratedValue(strategy = GenerationType.AUTO)
@Column(name="ID_FACTURA")
private Long id;
La entidad DETALLE_FACTURA tiene la clave primaria compuesta por dos campos: ID_FACTURA y NRO_ORDEN. En java, toda la clave primara es un objeto con el mismo nombre de la clase primaria más el sufijo "PK". Pero además, esta clave primaria debe tener una referencia a la misma factura de quien pertenece. Entonces, debemos crear la entidad primaria así:
@Embeddable
public class FacturaDetallePK implements java.io.Serializable {
@Column(name="id_factura",nullable=false)
private int idFactura;
@Column(name="nro_orden",nullable=false)
private int nroOrden;
Como se ve, solo va el atributo que se enlazará con la tabla, que debe ser del mismo tipo (a menos que especifique lo contrario).
Ahora, al mapear la entidad FACTURA_DETALLE, esta debería tener la clave primaria (PK) además, del objeto que hará referencia con su 'padre', es decir, con FACTURA:
@Entity
@Table(name="FACTURA_DETALLE")
public class FacturaDetalle implements java.io.Serializable {
@EmbeddedId
private FacturaDetallePK facturaDetallePK;
@JoinColumn(name="ID_FACTURA",referencedColumnName="ID_FACTURA")
@ManyToOne
private Factura factura;
Se podrá pensar "pero, no se estará haciendo redundancia?, porque ya en el PK ya está el objeto Factura. tengo que volverlo a declarar como atributo de FacturaDetalle". Pues sí, de otra manera el API no podrá saber cómo hacer referencia desde la entidad FACTURA_DETALLE con FACTURA.
"¿No se haría más pesado tener que programar que cada vez que agrego una detalle a la factura colocar en ambos atributos el valor de su cabecera?"
Bueno, sí, pero utilizando una buena implementación del patrón DAO, este se puede hacer cargo de él. Además, debería de hacer persistente a cada línea de detalle. Aquí un ejemplo:
emf = Persistence.createEntityManagerFactory("facturaPU");
Factura factura=new Factura();
FacturaDetalle det1=new FacturaDetalle();
det1.setDescripcion("PCs");
FacturaDetalle det2=new FacturaDetalle();
det2.setDescripcion("Monitores");
persist(factura);
factura.agregarDetalle(det1);
persist(det1);
factura.agregarDetalle(det2);
persist(det2);
Y el método agregarDetalle() sería así:
@OneToMany(cascade = CascadeType.ALL, mappedBy = "factura")
private Collection<FacturaDetalle> facturaDetalleCollection=new ArrayList<FacturaDetalle>();
void agregarDetalle(FacturaDetalle det) {
this.facturaDetalleCollection.add(det);
det.setFacturaDetallePK(new FacturaDetallePK(this.facturaDetalleCollection.size(),this.idFactura));
}
Hace mucho buscaba una solucion a esto, gracias.
ResponderBorrar