Aplicatii client/server cu baze de date: PERSISTENTA

Dezvoltare aplicatii cu baze de date folosind platforma Java

Java Persistence API (sau Architecture) in NetBeans

Problema maparii O/R a generat in comunitatea Java o confruntare intre mai multe solutii mai mult sau mai putin comerciale. Dintre acestea merita amintite cel putin Hibernate, TopLink sau Kodo (SolarMetric). Popularitatea acestor motoare O/R a prevalat in cele din urma fata de existentul standard de persistenta J2EE materializat sub forma entitatilor EJB 2.0. Ecosistemul JEE a oferit astfel cadrul perfect pentru standardizarea specificatiilor de persistenta care sa fie implementate tehnologic de existentele motoare O/R care sa garanteze prin maturitatea lor fezabilitatea cadrelor de lucru oferite formalizate in JPA (Java Persistence API) si JDO (Java Data Objects). Stabilizarea in acest fel a cadrelor de lucru pentru persistenta a avut mai multe efecte majore benefice: prezervarea portabilitatii SQL fata de diferitele motoare de baze de date obtinuta la nivelul standardului de baza JDBC, portabilitatea la nivelul solutiilor de implementare a modelelor de persistenta proiectate pe specificul diferitelor aplicatii, portabilitatea la nivelul stilului arhitectural (aplicatii pe doua straturi cu nivelul de persistenta rezident pe partea desktop vs. aplicatii pe trei straturi cu nivelul de persistenta plasat pe partea componentelor business distribuite EJB), standardizarea suportului pentru persistenta sub forma unor module funtionale dedicate la nivelul celor mai populare medii integrate de dezvoltare, NetBeans, Eclipse, JDeveloper etc.

Invocarea suportului NetBeans pentru persistenta

In continuare vom descrie caracteristicile cele mai populare ale motoarelor bazate pe arhitectura JPA sprijinindu-ne pe suportul oferite de NetBeans in acest sens. Arhitectura stratificata pe care o luam in considerare are in vedere aplicatii container-desktop cu baze de date, insa, la nivelul specificatiilor O/R lucrurile nu difera dramatic fata de arhitecturile distribuite bazate pe containere EJB.

VARIANTA 1: Activarea bazei de date interne ("embedded") Derby

O modalitate comoda de a testa lucrul cu framework-ul de persistenta JPA consta in utilizarea motorului de baze de date JavaDerby care este "incapsulat" implicit in platforma de dezvoltare Java Standard Edition si este accesebil direct din mediul NetBeans, fereastra Services.

Crearea unei baze de date accesibila folosind motorul Derby este o sarcina relativ triviala. Astfel, din meniul contextual al nodului JavaDB din fereastra Services este apelata optiunea Create Database.

Va fi lansata astfel fereastra Create Java DB Database, in care trebuie completate rubricile referitoare la numele bazei de date si numele + parola utilizatorului proprietar al bazei de date. Foarte important, butonul Proprieties deschide fereastra Java DB Properties care contine rubrica Database Location de unde se poate specifica directorul in care va fi depozitata fizic baza de date nou creata. Implicit bazele de date sunt create intr-un direct din profilul utilizatorului curent al S.O., de acceea aducerea bazei de date intr-o locatie apropriata proiectului poate fi realizata in maniera ilustrata mai jos:

Dupa pornirea motorului Apache DerbyDB si crearea bazei de date, in nodul databases din mediul NetBeans va apare o conexiune catre noua baza de date, care poate fi folosita pentru a accesa in mod "SQL" structurile relationale care vor fi generate prin framework-ul JPA.

Urmatorul pas consta in crearea configuratiei unui spatiu de persistenta in aplicatia Java. Obiectele care vor fi continute sau se vor regasi intr-un spatiu de persistenta reprezinta, bineinteles, obiecte persistente, adica obiecte care au o stare persistenta concretizata intr-o baza de date. Daca vor fi aduse obiecte noi intr-un spatiu de persistenta atunci ele vor fi "inserate" in baza de date, iar daca vor fi modificate obiecte persistente reconstituite din baza de date, ele vor fi resinconcronizate cu baza de date.

Configurarea unui spatiu de pesistenta asociat proiectului aplicatiei Java se realizeaza din optiunea New Persistence Unit (sau New Others Persistence (category) Persistence Unit) precum in figura de mai jos.

Framewok-ul JPA, adica Java Persistence API, este de fapt doar un standard (o specificatie declaratica). El devine "operabil" prin implementarea furnizata de un producator, in cazul de mai jos TopLink. O alta informatie necesara este legata de rubrica Database Connection ce poate fi completata prin selectarea conexiunii noii baze de date generate dupa cum am exemplificat mai sus.

Rubrica Table Generation Strategy asigura transformarea claselor entitati din aplicatie in structuri (tabelare) din baza de date daca se va selecta una din optiunile Create sau Drop and Create. Ceea ce se va genera este defapt un fisier precum cel de mai jos.

Crearea unui element de tip PersistenceUnit a avut drept consecinta si adaugarea intre dependentele proiectului a bibliotecilor TopLink care furnizeaza implementarea JPA utilizata. Fapt vizibil prin expandarea nodului Libraries din fereastra Projects.

Pentru ca spatiul de persistenta sa devina functional va trebui sa adaugam intre dependentele proiectului si biblioteca Java DB Driver ce contine driver-ele JDBC necesare conectarii la motorul Derby.

Sau, daca aveti arhiva jar continand doar driverul JDBC, aceasta poate fi inlcusa direct intre dependentele proiectului, fara a mai folosi vreo biblioteca intermediara.

Dupa ce a fost creata o "unitate de persistanta" si au fost aduse proiectului dependentele catre implementarea JPA si driverele JDBC, se poate trece la crearea primelor clase entitati folosind optiunea New Entity Class din meniul contextual:

VARIANTA 2: Conectarea la o baza de date PostgreSQL existenta

In eventualitatea preexistentei unei baze de date (PostgreSQL) ce contine schema relationala ce va asigura suportul concret de persistenta a claselor entitati din proiect, atunci, fata de exemplu anterior referitor la crearea unei noi baze de date Derby, primul lucru care trebuie facut consta in realizarea unei conexiune JDBC la aceasta baza de date, parcurgand urmatorii pasi:

Indicarea driverului de lucru cu serverul bazei de date, in exemplu nostru driverul PostgreSQL

Configurarea unei conexiuni de lucru cu serverul de baze de date pe baza driverului indicat mai sus prin apelarea optiunii Connect using din meniul contextual asociat acestuia:

Deschiderea conexiunii astfel create si eventual initierea unui dialog SQL din fereastra deschisa prin apelarea optiunii Execute Command din meniul contextula asociat

In fine, la fel ca si in cazul bazei de date Derby, si in acest caz se poate trece la crearea primei clase entitati odata cu activarea primei "unitati de persistenta", parcurgand in acest scop urmatorii pasi:

1. Crearea sau deschiderea unui proiect de tipul aferent aplicatiilor Java SE (pentru aplicatii Java desktop) si apelarea optiunii New Entity Class din meniul contextual aferent pachetului destinat claselor din modelul afacerii aferente.

2. Intentia este declararea initiala entitatii Client ca simbioza intre o clasa numita Client si tabela CLIENTI in schema relationala avuta la dispozitie. Una din caracteristicile esentiale ale claselor desemnate ca entitati persistente este identitatea, motiv pentru care desemnam ca tip al proprietatii care va implementa acest aspect tipul Integer.

3. Inainte de a incheia procesul initial de declarare a entitatii Client, va trebui obligatoriu, pentru o mai facila modalitate de gestionare a informatiilor de configurare a stratului de persistenta, crearea unei unitati de persistenta (daca aceast lucru nu a fost deja realizat intr-o etapa premergatoare). In NetBeans, obtinerea acesteia in acest pas se realizeaza actionand butonul Create Persistence Unit din dialogul New Entity Class si implica trei specificatii importante: un nume (JAppPU), o biblioteca ce contine elementele de implementare a arhitecturii JPA pe o solutie concreta (TopLink) si o conexiune JDBC la baza de date (jdbc:postgresql ).

Ca urmare a acestui proces va rezulta

a.       O clasa denumita Client "imbogatita" cu o serie de adnotari (@) care vor constitui baza maparii elementelor specifice modelului OO cu schema relationala

b.      Fisierul persistence.xml. plasat in subdirectorul META-INF care va descrie in XML configuratiile unitatii de persistenta create. Editarea acestui fisiere se face cel mai comun in modul grafic sau text.

Elementele de configurare esentiale se refera la:

• Providerul JPA <provider>;
• Informatiile <properties> de conectare prin JDBC la baza de date;
• Numele claselor entitati <class> care vor fi gestionate de stratul de persistenta.

Implicarea providerului TopLink ca suport de persistenta JPA in aplicatia noastra se manifesta prin adaugarea automata in resursele biblioteci ale acesteia a arhivelor JAR top-link-essential.jar si top-link-essential-agent.jar. Pentru ca la configurarea initiala a unitatii de persistenta am inidicat o conexiune JDBC pentru baza de date PostgreSQL va trebui sa adaugam in lista de biblioteci si driverul JDBC aferent .

Construirea claselor de mapare

Clasele de mapare vor fi construite dupa metodologia JavaBeans si vor contine adnotari (un fel de tag-uri - o facilitate noua oferita de versiunea 1.5 a limbajului Java) prin care vom preciza: tabela mapata, campurile cheie primara si, eventual, cum (si daca) trebuie generate valorile cheii primare. Adnotarile se realizeaza prin semnul @ urmat imediat (fara spatii) de cuvinte cheie specifice framework-ului cu care lucram (JPA - TopLink) adaugate inaintea declaratiei: unei clase, unui atribut sau unei metode.

Spre exemplu, clasa din listingul mai jos, rezultata din modificarea corepunzatoare a clasei Client initiale, specifica prin adnotari ca:

(1) este vorba de o entitate persistenta ( @Entity) care mapeaza tabela CLIENTI (numele tabelei poate fi prefixat de numele schemei in care rezida), (@Table)

(2) a carei cheie primara este data de atributul codcl[1](observam ca @Id este scris imediat inaintea declaratiei atributului propriu-zis) - valoarea acestui atribut va fi utilizata pentru a sincroniza starea obiectului Java din memoria interna a clientului cu inregistrarea corespunzatoare stocata pe serverul BD si pentru completarea criteriului implicit de cautare find(NumeClasaEntitate, valoareCheiePrimara).

IMPORTANT !

a.       De la bun inceput trebuie stiut ca: valoare unei chei (Id) poate fi data (sau generata) o singura data, la prima salvare a unui nou obiect in baza de date (atunci cand se creaza o noua inregistrare). Ulterior, stratul de persistenta JPA nu va permite modificarea valorii cheii (spre exemplu valoarea atributului codcl) pentru obiectele care au o inregistrare corespondenta in BD.

b.      (asa cum am mai precizat chiar la inceput) este indicata utilizarea claselor de acoperire (Double, Integer sau BigDecimal) si nu a primitivelor (int, double, float, etc) pentru atributele numerice.

Iata si celelalte clase de mapare:

Clasa entitate Factura:

import java.io.Serializable;

import java.util.Date;

import javax.persistence.Entity;

import javax.persistence.Id;

import javax.persistence.Table;

import javax.persistence.Temporal;

import javax.persistence.TemporalType;

@Entity

@Table(name='FACTURI')

public class Factura implements Serializable

public Factura(Integer nrfact)

public Integer getNrfact()

public Date getDatafact()

public Integer getCodcl()

public String getObs()

public void setNrfact(Integer valNoua)

public void setDatafact(Date valNoua)

public void setCodcl(Integer valNoua)

public void setObs(String valNoua)

public String toString()

public boolean equals(Object object)

Factura other = (Factura)object;

if (this.nrfact != other.nrfact &&

(this.nrfact == null ||

!this.nrfact.equals(other.nrfact)))

return false;

return true;

}

Clasa entitate Produs :

import javax.persistence.Entity;

import javax.persistence.GeneratorType;

import javax.persistence.Id;

import javax.persistence.Table;

@Entity

@Table(name='PRODUSE ')

public class Produs

public Produs(Integer codpr)

public Integer getCodpr()

public void setCodpr(Integer codpr)

public String getDenpr()

public void setDenpr(String denpr)

public String getUm()

public void setUm(String um)

public String getGrupa()

public void setGrupa(String grupa)

public Double getProctva()

public void setProctva(Double proctva)

public boolean equals(Object object)

Produs other = (Produs)object;

if (this.codpr != other.codpr &&

(this.codpr == null ||

!this.codpr.equals(other.codpr)))

return false;

return true;

}

In cazul in care avem de reprezentat specificat identitate mapata pe o cheie primara compusa trebuie in primul rand sa indicam folosind adnotarea @Id toate atributele care vor intra in componenta identificatorului. In al doilea rand, ar trebui construita o clasa aditionala (dupa aceeasi metodologie JavaBeans), care sa contina atributele cheii primare. Aceasta noua clasa trebuie sa implementeze operatorul de egalitate (sa suprascrie metoda equals()) din urmatoarea ratiune: stocarea interna a obiectelor persistente in colectii de tip Map implica identificarea acestora in operatiunile de cautare prin intermediul campului/campurilor marcate @Id. Doua obiecte sunt egale daca au atributele marcate @Id egale. Odata construita clasa pentru cheia compusa,vom utiliza o adnotare la nivel de clasa: @IdClass si adnotarea @Id la nivelul atributelor ce constituie "cheia primara"din clasa de mapare. Iata implementarea pentru cazul tabelei LINIIFACT.

Clasa de indentitate pentru entitatea LinieFactura :

public class LinieFacturaID

public LinieFacturaPK(Integer nrfact, Integer linie)

public boolean equals(Object object)

LinieFacturaPK other = (LinieFacturaPK)object;

if (this.linie != other.linie) return false;

if (this.nrfact != other.nrfact) return false;

return true;

}

Clasa entitate LinieFactura :

import java.io.Serializable;

import java.math.BigDecimal;

import javax.persistence.Entity;

import javax.persistence.Id;

import javax.persistence.IdClass;

import javax.persistence.Table;

import javax.persistence.UniqueConstraint;

@Entity

@Table(name = 'liniifact')

@IdClass(LinieFacturaID.class)

public class LinieFactura implements Serializable

public LinieFactura(Integer nrfact, Integer linie)

public Integer getNrfact()

public void setNrfact(Integer nrfact)

public Integer getLinie()

public void setLinie(Integer linie)

public BigDecimal getCantitate()

public void setCantitate(BigDecimal cantitate)

public BigDecimal getPretunit()

public void setPretunit(BigDecimal pretunit)

public Integer getCodpr()

public void setCodpr(Integer codpr)

public boolean equals(Object object)

LinieFactura other = (LinieFactura)object;

if (this.linie != other.linie) return false;

if (this.nrfact != other.nrfact) return false;

return true;

}

In cazul in care ar mai exista un criteriu de unicitate pe care s-ar dori generat la nivelul structurilor relationale, atunci acesta poate fi specifict prin parametrul uniqueConstraints din adnotarea Table. De exemplu, daca ar exista restrictia ca un produs poate fi specificat o singura data pe o factura atunci la nivelul clasei LinieFactura adnotarea Table ar putea fi urmatoarea:

@Entity

@Table(name = 'liniifact',

uniqueConstraints = @UniqueConstraint(columnNames = ))

@IdClass(LinieFacturaID.class)

public class LinieFactura implements Serializable

Tranzactionarea obiectelor persistente: pentru primul test JPA

Am discutat deja mai sus modul in care mediul NetBeans ofera sustinere pentru configurarea unitatii de persistenta. Am mentionat de asemenea principalii parametri:

provider - numele furnizorului (din sistemul de bibloteci suport) implementarii gestionarului stratului de persistenta JPA;

class - care introduce fiecare clasa entitate;

grupul de proprietati (property) specifice gestionarului stratului de persistenta dintre care se pot mentiona: proprietatile de configurare a conexiunii cu baza de date, dar si posibilitatea generarii sau sincronizarii modelului de entitati specificat prin grupul de parametri classes cu schema relationala de mapare ( de ex. toplink.ddl-generation).

Prin urmare, dupa ce am creat clasele entitatilor de persistenta, numele acestora trebuie specificate in fisierul persistence.xml care contine parametrii de configurare grupati sub forma unei unitati de persistenta (persistence unit) necesara pentru initializarea unei instante EntityManagerFactory. O astfel de instanta factory reprezinta sursa de creare a managerilor de persistenta sub forma obiectelor EntityManager care are ca atributiuni interogarea bazei de date si reconstituirea obiectelor persistente, precum si salvarea acestora intr-un context tranzactional.

Adaugarea claselor entitati in unitatea de persistenta si configurarea strategiei de generare a schemei relationale este facilitata de mediul NetBeans prin posibilitatea editarii grafice a fisiserului persistence.xml sub forma urmatorului formular:

de unde putem actiona butonul Add class si selectarea claselor entitati detectate automat de mediul NetBeans si listate in fereastra Add Entity. Se observa, de asemenea selectarea strategiei Create pentru sincronizarea cu schema bazei de date ceea ce inseamna ca, in cazul in care lipseste tabela aferenta unei entitati (specificata prin @Table(name = .) ) atunci va fi creata automat.

Primul Test JPA

Desi, dupa cum am vazut mai sus, am ales strategia 'create-tables' pentru 'toplink.ddl-generation', scenariul pe care il vom urma in continuare presupune existenta tabelelor mentionate prin adnotarile @Table, ce urmeaza mentiunilor @Entity din codul sursa al claselor persistente, in schema bazei de date. Asa incat, deocamdata trebuie asigurata compatibilitatea tipurilor de date Java si SQL (de regula NUMERIC fara zecimale - Integer, NUMERIC cu zecimale - Double sau, mai bine, java.math.BigDecimal, DATE - cu java.util.Date plus mentiunea @Temporal(TemporalType.DATE), sau mai bine java.sql.Date ori java.sql.Timestamp, CHAR sau VARCHAR cu String etc.) precum si corespondeta nume atribute entitati - nume atribute relationale. In cazul in care aceasta ultima corespondeta nu se poate realiza direct, atunci inaintea fiecarui atribut al unei entitati se poate mentiona directiva @Column(name = "nume cimp tabela relationala").

Pentru test folosim clasa Main generata drept clasa principala, de initiere a executiei, proiectului aplicatiei noastre. Din fereastra de editare a codului sursa activam meniul contextual de unde invocam Persistence Use Entity Manager

Ca urmare vor fi adaugate in codul sursa mai multe linii de cod necesare pentru a invoca managerul de persistenta astfel:

import japp.model.Client;

import java.util.Collection;

import javax.persistence.EntityManager;

import javax.persistence.EntityManagerFactory;

import javax.persistence.Persistence;

public class Main

public void persist(Object object) catch (Exception e) finally

}

Observam mai intai obtinerea unei instate EntityManagerFactory pe baza unitatii de persistenta si apoi invocarea contextului tranzactional pentru o instanta EntiyManager.

Inspirandu-ne din modelul tranzactional propus vom adauga metoda exemplu tranzactClienti in care:

dupa obtienerea managerului de persistenta (linia 2) clientul cu codul 1001 (valoare a cheii primare) este reconstituit din baza de date (4) prin intermediul metodei find(TipEntitate, valoare-cheie-primara) si modificat la fel ca un POJO[2] obisnuit si salvat in baza de date (9) in contextul tranzactiei deschise (7) inaintea operatiei proprizise si inchise cu success (10) sau prin anulare (13) daca survine vreo exceptie;

pentru adaugarea unui client nou acesta este instantiat folosind de preferinta un constructor care sa initializeze cel putin cheia primara (16) fiind apoi salvat intr-un context tranzactional la fel ca mai sus;

afisarea tuturor clientilor din baza de date, inclusiv cei doi mentionati mai sus, se poate face folosind metoda createQuery() oferita de managerul de persistenta (28). Aceasta metoda primeste ca argument o fraza in limbajul EJBQL si returneaza o instanta javax.persistence.Query ce ofera la randul ei pentru executie si gestionarea rezultatului executiei sub forma unei colectii de obiecte metoda getResultList();

stergerea unui obiect se face tot in context tranzactional dar invocand in locul metodei persist(Object) metoda remove(Object).

public static void tranzactClienti() catch (Exception e) // adaugare client nou client = new Client(1201); client.setDencl('Client 201'); em.getTransaction().begin(); try catch (Exception e) // afisare lista clienti Collection<Client> clienti = em.createQuery('SELECT c FROM Client c').getResultList(); Iterator<Client> i = clienti.iterator(); while(i.hasNext()) System.out.println(i.next().getDencl()); // stergere client em.getTransaction().begin(); try catch (Exception e) finally   }

Implementare relatiilor de asociere

Modelul orientat obiect al entitatilor persistente rezultat pina acum are totusi cel putin un anumit neajuns: nematerializarea directa a relatiilor de asociere. Astfel ca, la acest moment, daca dorim sa obtinem facturile asociate unui client ar trebui procedat astfel:

Client client = em.find(Client.class, <clientPK>);

Collection<Factura> facturi =

em.createQuery('SELECT f FROM Factura f WHERE f.codcl = :cod').

setParameter('cod', client.getCodcl()).getResultList();

sau invers, pentru cautarea clientului aferent unei facturi trebuie procedat astfel:

Factura factura = em.find(Factura.class, <facturaPK>);

Client c = (Client) em.createQuery('SELECT c FROM Client WHERE c.codcl = :cod').

setParameter('cod', factura.getCodcl()).getSingleResult();

Dupa cum se observa si mai sus asocierea programatica a entitatilor Client si Factura se face urmand de fapt corepondeta cheie-straina cheie-primara care materializeaza asocierile dintre entitati la nivel relational. Din fericire, cadrul de lucru JPA ofera solutii elegante in acest sens pentru gestionarea automata a relatiiilor 1-M, M-1, 1-1 sau chiar M-M.

Implementare si mapare asocieri 1-M si M-1

Legatura Client - Factura este o legatura M din perspectiva facturii sau 1 M din perspectiva clinetului. In orice caz, pentru simplificare cosideram drept sursa a asocierii acea entitate care corespunde tabelei ce contine cheia straina, in cazul nostru Factura. Atributul entitatii care reflecta cheia straina va fi inlocuit cu un atribut de tipul clasei destinatie a asociatiei (in cazul nostru Client) si va fi insotit de directiva @ManyToOne, dar si de directiva @JoinColumn care sa indice numele coloanei din tabela relationala desemnata drept cheie straina. La capatul celalalt al asociatiei, adica in clasa Client pentru exemplul nostru, va fi introdus un nou membru-colectie ce va fi precedat de directiva @OneToMany care va indica prin argumentul mappedBy numele atributului corepondent din entitatea asociata (Factura).

Clasa Factura va fi modificata dupa cum urmeaza:

Eliminam membrul codcl si il inlocuim cu client

private Integer codcl;

public Integer getCodcl()

public void setCodcl(Integer valNoua)

@ManyToOne

@JoinColumn(name = 'codcl')

private Client client;

public Client getClient()

public void setClient(Client client)

Iar clasa Client va fi modificata astfel:

// Adaugam membrul colectie facturi

@OneToMany(mappedBy = 'client')

private List<Factura> facturi = new ArrayList<Factura>()

public List<Factura> getFacturi()

public void setFacturi(List<Factura> facturi)

sau, daca declaratia colectiei nu este tipizata:

@OneToMany(targetEntity = Factura.class, mappedBy = 'client')

private Listfacturi = new ArrayList ();

public List getFacturi()

public void setFacturi(List facturi)

Atributul cascade al adnotarii @OneToMany are drept utilitate salvarea (si stergerea) in cascada si a elementelor de tipul clasei asociate.

La fel putem proceda in cazul asocierilor Factura-LinieFactura si Produs-LinieFactura. LinieFactura va fi sursa ambelor asociatii din moment ce tabela pe care este mapata contine ambele chei straine

FACTURI			LINIIFACT			PRODUS
nrfact	PK		nrfact	PK1/FK1		codpr	PK
datafact			linie	PK1/FK2		denpr
codcl	FK		codpr	FK		um
			cantitate			grupa
			pretunit			proctva

Ca urmare in entitatea LinieFactura vom defini un nou membru de tip Factura si vom inlocui membrul codpr cu un altul de tip Produs:

@Id @Column(name = 'nrfact' , insertable=false, updatable=false)

private Integer nrfact;

@Id

private Integer linie;

private Integer codpr;

public Integer getCodpr()

public void setCodpr(Integer codpr)

@ManyToOne @JoinColumn(name = 'codpr')

private Produs produs;

public Produs getProdus()

public void setProdus(Produs produs)

@ManyToOne

@JoinColumn(name = 'nrfact')

private Factura factura;

public Factura getFactura()

public void setFactura(Factura factura)

Pentru a include din punct de vedere logic asociatia cu Factura in componenta identificatorului mapat pe o cheie primara compusa, dupa cum am discutat, anterior, trebuie subliniate urmatoarele elemente:

• maparea atributului nrfact, prin @Column si a atributului factura, prin @JoinColumn, au aceeasi tinta: coloana nrfact;
• dintre cele doua mapari numai una singura este actualizabila, si anume cea de la nivelul atributului factura, atributul nrfact fiind protejat prin parametrii insertable=false, updatable=false ai adnotarii @Column, prin urmare actualizarea coloanei nrfact in baza de date se face numai datorita asocierii prin membrul factura cu clasa Factura.

In clasa Factura vom adauga colectia liniifactura:

@OneToMany(mappedBy = 'factura', cascade = CascadeType.ALL)

private List<LinieFactura> liniifactura = new ArrayList<LinieFactura>

public List<LinieFactura> getLiniifactura()

public void setLiniifactura(List<LinieFactura> liniifactura)

Atributul cascade al adnotarii @OneToMany are drept utilitate salvarea (si stergerea) in cascada si a elementelor de tip LinieFactura asociate cu cu obiectul-entitate factura in structura caruia este definita colectia liniifactura.

In clasa Produs vom adauga membrul liniifacturi

@OneToMany(mappedBy = 'produs')

private List<LinieFactura> liniifacturi;

public List<LinieFactura> getLiniifacturi()

public void setLiniifacturi(List<LinieFactura> liniifacturi)

Implementare si mapare asocieri M-M

Pentru a exemplifica asocierile M-M, vom "forta" exemplul anterior in acest sens, motiv pentru care, pentru a putea reveni la modelul initial, vom considera modificarile urmatoare intr-o versiune context proiect paralel cu cel din paragraful anterior. In acest nou proiect, legaturile entitatii LinieFactura vor fi reprezentate luand in considerare asocierea Factura-Produs de tip M M, clasa LinieFactura intermediind de fapt acest tip de asociatie (fiind apropiata astfel de semantica clasei-asociatie din UML). In acest caz vom adaga colectia produse in entitatea Factura si colectia facturi in entitatea Produs pentru a le lega direct.

Astfel in clasa Factura vom adauga urmatoarea secventa de cod:

@ManyToMany

@JoinTable(

name = 'liniifact',

joinColumns = @JoinColumn(name = 'nrfact'),

inverseJoinColumns = @JoinColumn(name = 'codpr')

)

private Collection<Produs> produse;

public Collection<Produs> getProduse()

public void setProduse(Collection<Produs> produse)

iar in clasa Produs vom adauga urmatoarea secventa de cod:

@ManyToMany(mappedBy = 'produse')

private Collection<Factura> facturi;

public Collection<Factura> getFacturi()

public void setFacturi(Collection<Factura> facturi)

Clasa LinieFactura ar putea ramane neschimbata, sau, pentru un spor de eleganta, ar putea fi transformata astfel: cele doua atribute marcate cu @Id drept compunand cheia primara vor fi inlocuite cu un singur atribut pe care il vom numi simplu id de tipul clasei cheie primara LinieFacturaPK si care va fi marcat cu @EmbeddedId. De asemenea vom elimina directiva @IdClass din entitate si vom adauga directiva @Emeddable in clasa cheie primara pe care o vom obliga sa implementeze si interfata java.io.Serializable. In final aceste clase vor arata astfel:

Clasa entitate LinieFactura:

import java.io.Serializable;

import java.math.BigDecimal;

import javax.persistence.EmbeddedId;

import javax.persistence.Entity;

import javax.persistence.JoinColumn;

import javax.persistence.ManyToOne;

import javax.persistence.Table;

import javax.persistence.UniqueConstraint;

@Entity

@Table(name = 'liniifact',

uniqueConstraints = @UniqueConstraint(columnNames = ))

//@IdClass(LinieFacturaPK.class)

public class LinieFactura implements Serializable{

// @Id

// private Integer nrfact;

// @Id

// private Integer linie;

// public Integer getNrfact()

// public void setNrfact(Integer nrfact)

// public Integer getLinie()

// public void setLinie(Integer linie)

@EmbeddedId

private LinieFacturaPK id;

public LinieFacturaPK getId()

public void setId(LinieFacturaPK id)

private BigDecimal cantitate;

private BigDecimal pretunit;

public LinieFactura()

public LinieFactura(LinieFacturaPK id)

// public LinieFactura(Integer nrfact, Integer linie)

public BigDecimal getCantitate()

public void setCantitate(BigDecimal cantitate)

public BigDecimal getPretunit()

public void setPretunit(BigDecimal pretunit)

// private Integer codpr;

// public Integer getCodpr()

// public void setCodpr(Integer codpr)

@ManyToOne

@JoinColumn(name = 'codpr')

private Produs produs;

public Produs getProdus()

public void setProdus(Produs produs)

@ManyToOne

@JoinColumn(name = 'nrfact')

private Factura factura;

public Factura getFactura()

public void setFactura(Factura factura)

Clasa cheie primara LinieFacturaPK:

import javax.persistence.Embeddable;

@Embeddable

public class LinieFacturaPK implements java.io.Serializable

Luind in considerare ultima versiune a claselor entitati putem reconstitui intregul complex de obiecte persistente pornind de la o singura interogare, de exemplu asupra clientilor:

public static void geEntities1()

}

em.close();

}

care ar trebuie sa produca un rezultat cum ar fi:

Client 2 SA

+-- Factura 1113 pe care s-au vindut:

| +-- Produs 2

+-- Factura 2113 pe care s-au vindut:

| +-- Produs 2

+-- Factura 3113 pe care s-au vindut:

+-- Produs 2

Client 3 SRL

+-- Factura 1119 pe care s-au vindut:

| +-- Produs 2

| +-- Produs 3

| +-- Produs 4

| +-- Produs 5

+-- Factura 2119 pe care s-au vindut:

| +-- Produs 2

| +-- Produs 3

| +-- Produs 4

| +-- Produs 5

+-- Factura 3119 pe care s-au vindut:

+-- Produs 2

+-- Produs 3

+-- Produs 4

+-- Produs 5

s.a.m.d

sau secventa de cod

public static void geEntities1()

}

em.close();

}

care ar trebuie sa produca un rezultat cum ar fi:

Client 2 SA

+-- Factura 1113 pe care s-au vindut:

| +-- Produs 2 in cantitatea 100 la pretul 975.00

+-- Factura 2113 pe care s-au vindut:

| +-- Produs 2 in cantitatea 120 la pretul 975.00

+-- Factura 3113 pe care s-au vindut:

+-- Produs 2 in cantitatea 120 la pretul 975.00

Client 3 SRL

+-- Factura 1119 pe care s-au vindut:

| +-- Produs 2 in cantitatea 35 la pretul 1090.00

| +-- Produs 3 in cantitatea 40 la pretul 700.00

| +-- Produs 4 in cantitatea 50 la pretul 1410.00

| +-- Produs 5 in cantitatea 750 la pretul 6300.00

+-- Factura 2119 pe care s-au vindut:

| +-- Produs 2 in cantitatea 35 la pretul 1090.00

| +-- Produs 3 in cantitatea 40 la pretul 700.00

| +-- Produs 4 in cantitatea 55 la pretul 1410.00

| +-- Produs 5 in cantitatea 755 la pretul 6300.00

+-- Factura 3119 pe care s-au vindut:

+-- Produs 2 in cantitatea 35 la pretul 1090.00

+-- Produs 3 in cantitatea 40 la pretul 700.00

+-- Produs 4 in cantitatea 55 la pretul 1410.00

+-- Produs 5 in cantitatea 755 la pretul 6300.00

s.a.m.d

Implementarea relatiilor de generalizare si definirea tabelelor relationale pentru ierarhii de mostenire

Pentru exemplele urmatoare, in primul rand vom reveni la versiunea asocierilor din paragradul in care am discutat maparile 1-M si M-1. Prin urmare clasa Factura este asociata cu clasa LinieFactura (si nu direct cu clasa Produse) prin membrul liniifactura.

Daca pana acum am folosit strategia maparii claselor entitati pe structuri relationale preexistente in schema bazei de date de lucru, in continuare vom exploata suportul NetBeans pentru generarea entitatilor pe baza tabelelor de mapare.

Tinta noastra este (1) generarea initiala a entitatii DocumentIncasare pe baza tabelei INCASARI si entitatii IncasareFactura pe baza tabelei INCASFACT care reprezentare a starilor asociatiei Factura - DocumentIncasare de tip M M; (2) dupa care vom crearea sub-clasele entitati OrdinPlata, Chitanta si CEC derivate din clasa DocumentIncasare si (3) definirea corepunzatoare a tabelelor in schema relationala pentru noile entitati.

Generarea entitatilor pe baza tabelelor existente in schema relationala

Avand la dispozitie deja schema relationala normalizata corespunzatoare modelului entitatilor persistente, putem profita astfel incat sa facem economie in ceea ce priveste efortul de codificare bazandu-ne in acest sens tot pe suportul NetBeans.

In acest sens trebuie sa parcurgem urmatorii pasi:

invocarea optiunii New Entity Classes from Databases din meniul contextual;

specificarea conexiunii JDBC si selectarea tabelelor pe baza carora vor fi construite entitatile persistente (caseta de bifare Include Related Tables ajuta la depistarea tabelor relationate pe baza cheilor straine ce vor genera asociatiile din modelul entitatilor). In acesta etapa aducem tabelele incasari si incasfact in lista Selected Tables fara a bifa si Include Related Tables (FACTURI este deja mapata pe entitatea Factura);

stabilirea numelor exacte si a pachetelor pentru clasele entitasi ce vor fi generate, in cazul nostru DocumentIncasare in corepondenta cu tabela incasari si IncasareFactura in corespondeta cu tabela incasfact;

in final vom analiza noile clase si celelalte elemente adaugate in proiect.

Astfel observam generarea fisierelor cod-sursa DocumenteIncasare.java, IncasareFactura.java si IncasareFacturaPK.java. De asemenea cele doua entitati deja sunt adaugate in lista claselor unitatii de persistenta (este actualizat fisierul persistence.xml). In fine, in special pentru a putea lucra cu metadatele schemei bazei de date chiar daca mediul NetBeans nu are o conexiune deschisa permanenta, este generat fisierul javadeveloper_Japp.dbschema stocat in acelasi director META-INF al aplicatiei ca si persistence.xml.

In continuare sa analizam mai in detaliu codul generat, care, excluzand comentariile ar putea fi urmatorul:

clasa entitate DocumentIncasare, are o cheie primara (id) simpla pe baza atributului codinc si, de asemenea, are o asociere 1-M cu clasa IncasareFactura prin atributul incasareFacturaCollection. In plus, pentru fiecare atribut al entitatii a fost creata cate o interogare a carui nume, bazat pe sablonul findBy<NumeAtribut> poate fi invocat direct de catre o instanta EntityManager prin metoda createNamedQuery().getResultList() sau getSingleResult() - cum este cazul interogarii dupa atributul cheie primara;

import java.io.Serializable;

import java.math.BigDecimal;

import java.util.Collection;

import java.util.Date;

import javax.persistence.CascadeType;

import javax.persistence.Column;

import javax.persistence.Entity;

import javax.persistence.Id;

import javax.persistence.NamedQueries;

import javax.persistence.NamedQuery;

import javax.persistence.OneToMany;

import javax.persistence.Table;

import javax.persistence.Temporal;

import javax.persistence.TemporalType;

@Entity

@Table(name = 'incasari')

@NamedQueries( )

public class DocumentIncasare implements Serializable {

@Id @Column(name = 'codinc', nullable = false)

private BigDecimal codinc;

@Column(name = 'datainc')

@Temporal(TemporalType.DATE)

private Date datainc;

@Column(name = 'coddoc')

private String coddoc;

@Column(name = 'nrdoc')

private String nrdoc;

@Column(name = 'datadoc')

@Temporal(TemporalType.DATE)

private Date datadoc;

@OneToMany(cascade = CascadeType.ALL, mappedBy = 'documentIncasare')

private List<IncasareFactura> incasari = new ArrayList<IncasareFactura>();

public DocumentIncasare()

public DocumentIncasare(BigDecimal codinc)

public BigDecimal getCodinc()

public void setCodinc(BigDecimal codinc)

public Date getDatainc()

public void setDatainc(Date datainc)

public String getCoddoc()

public void setCoddoc(String coddoc)

public String getNrdoc()

public void setNrdoc(String nrdoc)

public Date getDatadoc()

public void setDatadoc(Date datadoc)

public List<IncasareFactura> getIncasari()

public void setIncasareFacturaCollection

(List<IncasareFactura> incasari)

@Override

public int hashCode()

@Override

public boolean equals(Object object)

DocumentIncasare other = (DocumentIncasare)object;

if (this.codinc != other.codinc &&

(this.codinc == null ||

!this.codinc.equals(other.codinc))) return false;

return true;

}

@Override

public String toString()

in cazul entitatii IncasareFactura se observa de asemenea declararea grupului de interogari aferente fiecarui atribut si legatura inversa cu entitatea DocumentIncasare pe baza atributului documentIncasare (atentie la directiva @JoinColum prezenta ca urmare a faptului ca tabela de mapare incasfact detine cheia straina sursa a asociatiei). Cheia primara este declarata pe baza mecanismului @EmbeddedId, la fel cum am procedat in cazul entitatii LinieFactura, clasa desemnata a implementa identitatea fiind clasa @Embeddable IncasareFacturaPK

import java.io.Serializable;

import java.math.BigDecimal;

import javax.persistence.Column;

import javax.persistence.EmbeddedId;

import javax.persistence.Entity;

import javax.persistence.JoinColumn;

import javax.persistence.ManyToOne;

import javax.persistence.NamedQueries;

import javax.persistence.NamedQuery;

import javax.persistence.Table;

@Entity @Table(name = 'incasfact')

@NamedQueries( )

public class IncasareFactura implements Serializable

public IncasareFactura(IncasareFacturaPK incasareFacturaPK)

public IncasareFactura(IncasareFacturaPK incasareFacturaPK, BigDecimal transa)

public IncasareFactura(int nrfact, int codinc)

public IncasareFacturaPK getIncasareFacturaPK()

public void setIncasareFacturaPK(IncasareFacturaPK incasareFacturaPK)

public BigDecimal getTransa()

public void setTransa(BigDecimal transa)

public DocumentIncasare getDocumentIncasare()

@Override

public int hashCode()

@Override

public boolean equals(Object object)

IncasareFactura other = (IncasareFactura)object;

if (this.incasareFacturaPK != other.incasareFacturaPK &&

(this.incasareFacturaPK == null ||

!this.incasareFacturaPK.equals(other.incasareFacturaPK)))

return false;

return true;

}

@Override

public String toString()

Clasa de implementare a identitatii entitatii IncasareFactura

import java.io.Serializable;

import javax.persistence.Column;

import javax.persistence.Embeddable;

@Embeddable

public class IncasareFacturaID implements Serializable {

@Column(name = 'codinc')

private int codinc;

@Column(name = 'nrfact')

private int nrfact;

public IncasareFacturaID()

public IncasareFacturaID(int nrfact, int codinc)

public int getCodinc()

public void setCodinc(int codinc)

public int getNrfact()

public void setNrfact(int nrfact)

@Override

public int hashCode()

@Override

public boolean equals(Object object)

IncasareFacturaID other = (IncasareFacturaID)object;

if (this.nrfact != other.nrfact) return false;

if (this.codinc != other.codinc) return false;

return true;

}

@Override

public String toString()

Daca dorim si implementarea asociatiei M-M dintre Factura si DocumentIncasare, atunci va trebui sa adaugam in clasa Factura membru documente:

@ManyToMany

@JoinTable(

name = 'incasfact',

joinColumns = @JoinColumn(name = 'nrfact'),

inverseJoinColumns = @JoinColumn(name = 'codinc')

)

private Collection<DocumentIncasare> documente;

public Collection<DocumentIncasare> getDocumente()

public void setDocumente(Collection<DocumentIncasare> documente)

in DocumentIncasare atributul facturi:

@ManyToMany(mappedBy = 'documente')

private Collection<Factura> facturi;

public Collection<Factura> getFacturi()

iar in IncasareFactura:

@JoinColumn(name = 'nrfact', referencedColumnName = 'nrfact',

insertable = false, updatable = false)

@ManyToOne

private Factura factura;

public Factura getFactura()

public void setFactura(Factura factura)

Un test pentru a afisa de exemplu ordinele de plata ar putea arata astfel:

public static void geEntities3()

}

}

em.close;

}

Avind ca rezultat :

Nr. OP 111 din data Wed Aug 10 00:00:00 EEST 2005

+-- Factura incasata 1111 cu suma 53996.00

+-- Factura incasata 1118 cu suma 101975.00

Nr. OP 333 din data Tue Aug 09 00:00:00 EEST 2005

+-- Factura incasata 1117 cu suma 9754.00

+-- Factura incasata 1118 cu suma 100000.00

+-- Factura incasata 1120 cu suma 7315.00

Nr. OP 555 din data Wed Aug 10 00:00:00 EEST 2005

+-- Factura incasata 1113 cu suma 106275.00

Nr. OP 666 din data Thu Aug 11 00:00:00 EEST 2005

+-- Factura incasata 1117 cu suma 3696.00

(3) Crearea entitatilor din ierarhia de mostenire si generarea structurilor relationale de mapare a ierarhiei de mostenire

Exista mai multe strategii de mapare in tabele relationale a unei ierarhii de mostenire. Cea mai avantajoasa, dupa parerea noastra, implica :

pe langa tabela corepunzatoare clasei parinte, trebuie sa fie creata cite o tabela pentru fiecare sub-clasa asa incat cheia primara din tabela clasei parinte sa fie reluata in fiecare tabela corepunzatoare claselor copil si, in celasi timp, cheia primara din tabelele claselor copil sa fie declarata cheie straina catre cheia primara a tabelei "mama" a super-clasei:

CREATE TABLE ordineplata (

codinc NUMERIC(8) PRIMARY KEY,

bancaEmitenta VARCHAR(20),

nrcontPlatitor VARCHAR(20),

bancaIncasatoare VARCHAR(20),

nrcontIncasator VARCHAR(20)

CREATE TABLE cecuri (

codinc NUMERIC(8) PRIMARY KEY,

bancaEmitenta VARCHAR(20),

nrcont VARCHAR(20)

CREATE TABLE chitante (

codinc NUMERIC(8) PRIMARY KEY,

casier VARCHAR(20)

ALTER TABLE chitante

ADD CONSTRAINT fk_chit FOREIGN KEY (codinc) REFERENCES incasari(codinc);

ALTER TABLE cecuri

ADD CONSTRAINT fk_cec FOREIGN KEY (codinc) REFERENCES incasari(codinc);

ALTER TABLE ordineplata

ADD CONSTRAINT fk_op FOREIGN KEY (codinc) REFERENCES incasari(codinc);

super-clasa entitate va fi marcata prin directivele @Inheritence ce va indica strategia de mostenire (JOINED), si @DiscriminatorColumn care va indica acea coloana din tabela coreponzatoare (daca nu exista va fi creata) ce va diferentia prin valorile ei inregistrarile corepunzatoare fiecarei subclase, de exemplu coloana coddoc din tabela INCASARI cu valorile CEC, OP, CHIT corespunzatoare celor trei subclase CEC, OrdinPlata, Chitanta:

@Entity

@Table(name = 'incasari')

@Inheritance (strategy = InheritanceType.JOINED)

@DiscriminatorColumn(

name = 'coddoc', discriminatorType = DiscriminatorType.STRING

@NamedQueries( )

public class DocumentIncasare implements Serializable

fiecare subclasa va fi marcata ca entitate cu @Entity, va indica tabela de mapare cu @Table si va preciza valoarea corespunzatoare coloanei cu rol de discriminator prin @DiscriminatorValue, fara a defini insa explicit o cheie primara proprie @Id si fara a relua definitia cheii primare mostenite din super-clasa:

Subclas CEC:

import java.math.BigDecimal;

import javax.persistence.DiscriminatorValue;

import javax.persistence.Entity;

import javax.persistence.Table;

@Entity

@Table (name = 'cecuri')

@DiscriminatorValue('CEC')

public class CEC extends DocumentIncasare

public CEC(BigDecimal codinc)

public String getBancaEmitenta()

public void setBancaEmitenta(String bancaEmitenta)

public String getNrcont()

public void setNrcont(String nrcont)

Subclasa Chitanta:

import java.math.BigDecimal;

import javax.persistence.DiscriminatorValue;

import javax.persistence.Entity;

import javax.persistence.Table;

@Entity

@Table (name = 'chitante')

@DiscriminatorValue('CHIT')

public class Chitanta extends DocumentIncasare{

private String casier;

public Chitanta()

public Chitanta(BigDecimal codinc)

public String getCasier()

public void setCasier(String casier)

Subclasa OrdinPlata:

import java.math.BigDecimal;

import javax.persistence.DiscriminatorValue;

import javax.persistence.Entity;

import javax.persistence.Table;

@Entity

@Table (name = 'ordineplata')

@DiscriminatorValue('OP')

public class OrdinPlata extends DocumentIncasare

public OrdinPlata(BigDecimal codinc)

public String getBancaEmitenta()

public void setBancaEmitenta(String bancaEmitenta)

public String getNrContPlatitor()

public void setNrContPlatitor(String nrcontPlatitor)

public String getBancaIncasatoare()

public void setBancaIncasatoare(String bancaIncasatoare)

public String getNrContIncasator()

public void setNrContIncasator(String nrContIncasator)

Nu trebuie uitata adaugarea noilor entitati in unitatea de persistenta, adica actualizarea fisierului persistence.xml.

In fine, un simplu test pentru a instatia o subclasa ar putea arata astfel:

public static void newDocumentIncasare() catch (Exception e) finally

}