[JAVA] Rendere persistenti classi di dati

[-gia82-]

SALVE RAGAZZI SONO NUOVO SUL FORUM.MI SONO ISCRITTO PER VEDERE SE QUALKUNO DI VOI SA SPIEGARMI ALCUNE COSE.
GUARDATE QUESTE DUE CLASSI.



public class Tournament{
private List<Player> players; /* lista di oggetti di tipo Player */
private int Idtorneo;
public Tournament(){
players=new Player[20];
}
public void addPlayer(Player p)}{
players.add(p);
}
public void RemovePlayer(....){
..... ..... ....
}}


publi class Player {
String Nome,Cognome,CF,

/*vari metodi di get e set */

}



Queste due classi implementano l'associazione "A" :Un player partecipa ad un solo torneo e un torneo e "partecipato" da più player.

Ora i miei dubbi.Se volessi rendere persistente queste classi con le relative informazioni sull'associazione,usando un database relazionale(Mysql) ,l'associazione A l'implemento creando 2 tabelle TORNEO e PLAYER e inserendo nella Tabella PLAYER la chiave esterna che punta alla chiuave primaria di TORNEO(idTorneo).Ma a questo punto a che mi serve avere nella classe Tournamente un vettore di oggetti di tipo Player????Lo elimino?E modifico le mie classi inserendo nella classe Player una variabile istanza di tipo String che identifia la chiave esterna.In pratica tratto le mia classi come se fossero tuple nella tabella.
Quindi penso che la prima implementazione delle classi va bene solo quando ho a disposizione un Database Object oriented?E' così?



Non so se sono riuscito a farvi capire il mio problema.Se qualkuno mi sa rispondere.Anche in privato.
Aspetto notizie.

[alka]

Originariamente inviato da -gia82-
Se qualkuno mi sa rispondere.Anche in privato.

Nel rispetto della natura del forum, tutte le risposte devono essere inserite all'interno della discussione, fruibili da chiunque, e non fornite in privato.

[-gia82-]

nessuno mi sa spiegare qualkosa???

[nether]

Quindi penso che la prima implementazione delle classi va bene solo quando ho a disposizione un Database Object oriented?E' così?

No, basta che scrivi il codice necessario a "riempire" le proprieta' che rappresentano le relazioni.
Ad esempio, se nella tua classe Giocatore c'e' la proprieta "torneo" che rappresenta il Torneo al quale il giocatore e' iscritto, vorra' dire che quando farai la query per caricare un Giocatore dal database, farai anche un'altra query per tirare su il Torneo a partire dalla foreign-key relativa al Torneo presente nella tabella che ospita i dati del Giocatore...

p.s. Esistono alcuni framework (http://www.hibernate.org a mio parere su tutti) che permettono proprio di colmare la discrepanza tra una logica di progettazione a oggetti tipica di un linguaggio come java (le entita' che avevi progettato erano corrette da un punto di vista logico) e la realta' di un database che invece segue una logica relazionale.
Il suo uso non e' proprio la cosa piu' intuitiva e rapida del mondo, pero' c'e' veramente un sacco di documentazione in giro dalla quale prendere spunto.

[-gia82-]

Ho capito il discorso del riempire tutte le proprietà ecc ecc.Però,non si fa prima a trattare le classi come se fossero tuple di una tabella di un database?Così le relazioni N:1 le tratto inserendo la chiave esterna e quelle N:M le implmento creando una terza classe dove inserisco le chiavi esterne che si riferiscono alle entità della relazione.Quindi nell'esempio che ho fatto del torneo e giocatori,potrei fare le classi nel seguente modo:


public class Tournament{

private int Idtorneo ; /*altri attributi*/
public Tournament(){}

/* Metodi di get set */
}


publi class Player {
private String Nome,Cognome,CF,
private String torneo;
/*vari metodi di get e set */

}

In pratica quello che ho fatto è stato eliminare l'implementazione delle associazioni tramite collezioni di oggetti.Questa implementazione mi sembra molto più semplice da gestire dal punto di vista della persistenza.....che ne dici?

[nether]

sara' anche piu' semplice concettualmente ma non e' per nulla object-oriented... nessuno ti vieta di farlo ma non sfrutti le potenzialita' di una struttura delle entita' realmente ad oggetti (ereditarieta', navigabilita' bidirezionale da padre a figli e da figlio a padre, ecc.).

Insomma secondo me se implementi da subito un sistema "realmente" a oggetti, ti risparmi un sacco di menate in seguito (non dovrebbe essere una cosa molto complicata nel tuo caso, puoi farlo "a mano" senza usare nessun framework). Il fatto che come dici tu sia piu' semplice gestire la persistenza secondo me e' solo un'illusione, perche' un'architettura delle entita' solida ti elimina una serie di problemi successivi in fase di gestione dei dati che altrimenti ti ritroveresti.

[-gia82-]

Ovviamente ti ringrazio per le tue risposte,ma d'altronde c'è sempre qualkuno che non ha capito qualkosa e qualkuno che già la sa e la spiega a quello che non l'ha capita


Quello che devo imparare è gestire manualmente la persistenza dei dati in un database relazionale.Ad esempio,tornando alla mia prima implementazione delle classi torneo e giocatore.Se nel database c'è un Torneo A che ha già n giocatori che vi partecipano.Se ho l'esigenza di aggiunge un nuovo giocatore e poi salvare nel database il tutto.Io dovrei procedere nel seguente modo?una sorta di pseudo codice )

1)Caricare il torneo A tramite query .
2)Caricare la collezione di n giocatori,tramite query ,che già vi parteciapno e aggiungerli al torneo A
3)Creare un nuovo oggeto gioctore (n+1 esimo giocatore,cioè il nuovo giocatore che volgio inserire nel torneo) usare il metodo addPlayer(n+1 esimo giocatore) su TornoA precedentemente caricato(ora nella collezione di TorneoA ci sono n+1 giocatori)
4)Salvare il nuovo stato del TorneoA nel database :Andare a fare un inserimento nella tabella GIOCATORI del solo n+1 esimo giocatore.(dato che gli n giocatori precedenti già sono nel database).


Sarebbe questo un modo di gestire la persistenza dei dati? :master:
Oppure basta che inserisco il nuovo giocatore nella Tabella GIOCATORI e gli setto la chiave esterna (nel database)in modo che punti a TorneoA?
Il riempimento di tutti gli attributi di un oggetto (come ho fatto all'inizio) forse non è sempre necessario?E se no,quando è il caso di effettuarlo?

Ovviamente aspetto uan tua replica

[nether]

Oppure basta che inserisco il nuovo giocatore nella Tabella GIOCATORI e gli setto la chiave esterna (nel database)in modo che punti a TorneoA?

Nel tuo caso basta questo, non e' necessario che setti entrambi i lati della relazione (cioe' che setti un Torneo ad un Giocatore e aggiungi anche il Giocatore nella collection di Torneo).
Infatti, se ci pensi, nel database e in particolare nella tabella "torneo", non cambia una virgola se i giocatori ad esso associati sono 0, 1, 20, 100, 101...
Dal momento che la query per "riempire" la collection di Giocatore nella tua classe Torneo sara' qualcosa tipo (pseudo-sql) "select * from giocatore where giocatore.torneo_id = torneo.id", ti basta solamente inserire un nuovo record nella tabella giocatore riempendo la colonna che indica il torneo di appartenenza (torneo_id).

Se poi vuoi, nessuno ti vieta di scrivere il codice per gestire il fatto che se inserisci un Giocatore nella collection di un Torneo, e salvi l'oggetto Torneo nel database, automaticamente ti viene creato o aggiornato anche il record del Giocatore che e' stato appena aggiunto...
Vedi tu se ti serve o meno, potrebbe essere abbastanza carino da fare.

[-gia82-]

Ah ok potrei implementare il metodo più costoso in termini di memoria tanto ormai i calcolatori non hanno più problemi di ram.Quindi l'unica operazioni in cui ho necessita di riempire prima la collezione (di tutti i giocatori nel torneoA)è quello in cui mi viene chiesto di visuallizzare ad esempio tutti i giocatori che partecipano al torneoA,secondo mio parere,perchè altrimenti è tutto fumo e niente arrosto inserire collezioni di oggetti in una classe per implementare una relazione se poi nemmeno la uso (non la riempio mai....)

[nether]

altrimenti è tutto fumo e niente arrosto inserire collezioni di oggetti in una classe per implementare una relazione se poi nemmeno la uso (non la riempio mai....)

certo, non e' mica detto che tutte le relazioni debbano essere x forza bidirezionali... se reputi ad esempio che ti serve sapere, dato un giocatore, il torneo al quale questo giocatore e' iscritto, ma non e' essenziale sapere, dato un torneo, tutti i giocatori che vi sono iscritti, puoi semplicemente levare la collection di Giocatore dalla classe Torneo.