[Generico/OOP]Entità e tabelle con relazioni

[RaouL_BennetH]

Ciao a tutti :)

Ho diverse lacune da colmare per la comprensione su come rappresentare a livello di classi e oggetti, delle tabelle di un database che hanno fra di loro relazioni e vincoli.

Mi spiego meglio:


//Tabella Lavoratore
id_lavoratore
nome
cognome


//tabella TipologieContratti
id_tipoContratto
descrizione

//tabella CategoriaLavoratore
id_categoria
descrizione


//Tabella ContrattoLavoratore
id_tipoContratto
id_categoria
id_lavoratore
turno
....



Per quanto riguarda le tre tabelle principali, al momento mi sono limitato a rappresentarle con tre classi(Lavoratore, TipiContratto, Categoria).

Ho qualche perplessità su come procedere per la tabella 'ContrattoLavoratore'.

La rappresentazione delle entità che ho fatto sino ad ora è molto elementare:



public class Lavoratore
{
public int id;
public string nome;
public string cognome;
}

//et similia per le altre due
//ho poi definito un'interfaccia

Interface AzioniAziendali
{

void AddLavoratore(Lavoratore lavoratore);
void AddTipiContratto(TipiContratto tipoContratto);
void AddCategoriaLavoratore(Categoria categoria);
}



La prima cosa che mi è saltata agli occhi, è che l'interfaccia così come è non ha senso, dato che, dovendola implementare per le classi, dovrei far implementare appunto a dette classi metodi che a loro non servono.

Quindi, la prima domanda è:

Devo inevitabilmente utilizzare un'interfaccia specifica per ogni classe volendo 'abituarmi' ad essere obbligato a descrivere comportamenti?


La seconda invece riguarda proprio il dilemma della progettazione per la classe ContrattoLavoratore; Questa classe ha pochi campi in comune con le altre;
non vedo ereditarietà, ma intuisco che si debba progettare in modo che quando verrà fatto un inserimento o un update sul db, si debba tenere conto di relazioni e vincoli.

Grazie in anticipo come sempre a tutti :)

RaouL.

[Kralizek]

perché hai pensato all'interfaccia?

[RaouL_BennetH]

perché hai pensato all'interfaccia?

Ciao :)

Per nessuna ragione in particolare tranne che si tratta del mio attuale argomento di studio.

RaouL.

[mad_hhatter]

non puoi sfruttare un ORM?

comunque, di solito, quando una classe che rappresenta un'entità ha dei vincoli referenziali verso altre entità si definisce un membro di un tipo particolare fatto apposta per incapsulare la gestione del vincolo corrispondente

[RaouL_BennetH]

non puoi sfruttare un ORM?


Sto già dando uno sguardo ad hibernate, ma diciamo che al momento, non essendo questa un'applicazione da 'lavoro', mi interessa più capire alcune cose di base a livello generico.



comunque, di solito, quando una classe che rappresenta un'entità ha dei vincoli referenziali verso altre entità si definisce un membro di un tipo particolare fatto apposta per incapsulare la gestione del vincolo corrispondente

ecco... non sono sicuro di aver capito bene :(

[mad_hhatter]

cerco di spiegarti (uso l'orm di django da un po', ma non posso certo dirmi un esperto...):

quando definisci una classe che rappresenta un'entità, i suoi membri che rappresentano gli attributi dell'entità rappresentata sono oggetti di vario tipo (ad esempio: IntegerField, TextField, ecc...) ognuno dei quali, immagino, gestisce la mappatura dell'attributo da esso rappresentato dal dominio degli oggetti a quello delle entità relazionali. In particolare sono definiti opportuni tipi per rappresentare le associazioni (ad esempio: OneToManyField, ManyToManyField, ecc) che, immagino, saranno responsabili di gestire a basso livello tutta l'integrità referenziale. In particolare, di solito, quando due classi rappresentano 2 entità tra loro in relazione, ognuna contiene uno specifico membro responsabile di tener traccia di tale relazione

[Giullo]

ti posso portare la mia esperienza con ActiveRecord, un ORM in ruby, utilizzato da diversi frameworks, tra cui rails.

la mappatura tra campi della tabella e membri della classe è 1:1, nel senso che ad un campo title di tipo varchar nella tabella, corrisponde una proprietà title di tipo stringa nella classe e così via ... per gestire i diversi tipi di relazioni (uno a uno, uno a molti, molti a molti etc etc) si utilizzano dei metodi della classe ActiveRecord che "istruiscono" l'istanza sulle relazioni in essere. cerco di spiegarmi con un esempio:

ho un tabella orders ed una users, legati da una relazione uno a molti. se nel campo ordini ho un campo user_id, posso dichiarare questa relazione così:

(all'interno della definizione della classe ordini)

belongs_to :user

(all'interno della definizione della classe utenti)

has_many :orders


questo mi permette di fare:
myorder.user per ottenere l'oggetto utente cui appartiene l'ordine
myuser.orders per avere un array degli ordini associati a quell'utente

quindi generalmente per tenere traccia di una relazione tra due entità avrai bisogno di una variabile in ciascuna entità