OOP Caricamento dati

[Fractals87]

Ciao a tutti,

Il mio problema riguarda la maniera più corretta per caricare i dati, vi spiego in che situazione sono
2 tabelle
Utenti
Tecnici

Sulla tabella utente ho il mio record dell'utente a cui può fare accesso all'applicazione.
Nel caso in cui l'utente appartenga al gruppo "tecnico" ha un record sulla tabella tecnici con altre informazioni.
Le due tabelle sono collegate con campo id

ho creato la mia classe utenti con un metodo "Load" che mi carica tt le info dell'utente con id passato.

Parlando a livello pratico mi trovo nella situazione di avere create oggetto utente, aver fatto il load, ma di aver necessità di recuperare anche le info presenti sul record tecnico.
Qual'è il miglior modo di procedere?

La soluzione che ho in mente è :
Presupponendo di avere la classe tecnico a disposizione,

Creo oggetto utente
Carico i dati
Recupero id
Creo oggetto tecnico con id recuperato
load del tecnico

Oppure c'è un modo più corretto di procedere?

Ciao e Grazie a tt

[satifal]

Innagino che la classe utente abbia un'istanza della classe tecnico ed al load dell'utente venga effettuato anche il load del tecnico.

[Fractals87]

No infatti è proprio quello che voglio capire come strutturare la classe utente/tecnico in questa situazione...

[Santino83_02]

No infatti è proprio quello che voglio capire come strutturare la classe utente/tecnico in questa situazione...

ma non hai fatto una query di join nel post precedente? Secondo me non era un metodo sbagliato di procedere.. più che altro perchè sembra che tu stia dicendo che tecnico è una estensione di utente, quindi sarei portato a dire che la classe Tecnico estenda quella Utente, quindi il load è sulla classe tecnico non Utente... boh poi non so se possa andare bene come logica nella tua app... altrimenti la tua classe User dovrebbe avere tanti getTipologia quanti sono le possibilità nel database, ovvero getTecnico, getResponsabile, getFoo, getBar... carichi tali infomazioni o al momento del "get" (in lazy loading) o al load della classe (eager loading)

[Fractals87]

Anche a me pare di capire che tecnico estenda utente.
Inoltre posso dire con sicurezza che la classe tecnico dovrà avere metodi proprietari che non centrano con utente ma solo con i dati del tecnico.Premesso se l'utente è di livello amministratore non ha record tecnico...
La join era per avere tutti i dati (Qual'ora ci fossero).

/* IPOTESI 1*/
class utente{
  //proprieta
  public function load(id){
     //setta le proprietà
  }
}

class tecnico{
  //proprieta
  public function load(id){
     //setta le proprietà
  }
}

test.php
$utente = new utente();
$utente->setID($id);
$utente->load();
if($utente->livello=="tecnico")
    $tecnico = new tecnico();
    $tecnico->load($user->getId())
/* IPOTESI 1 */

/* IPOTESI 2*/
class utente{
  //proprieta
  public function load(id){
     //setta le proprietà
  }
}

class tecnico extends utente{
  //proprieta
  public function load($id){
     //setta le proprietà
     parent::Load($id); // setto anche le proprietà utente
  }
}

test.php
$tecnico = new tecnico();
$tecnico->setId($id);
$tecnico->load();
/* IPOTESI 2 */ 

Se io metto un getTecnico() all'interno della classe utente sarei costretto a inserire una serie di metodi, appartenenti al tecnico nella classe user, non mi sembra corretto... almeno da quanto ho capito delle classi....

Il metodo (eager loading) è come la mia ipotesi 2?

Aggiornamento magari utile...
un utente di livello amministratore ha solo il record "utente"
un utente di livello tecnico ha record "utente" e record "tecnico"

[Al_katraz984]

io opterei per mantenere separate le entità

un utente può essere anche un tecnico, ma anche no..

con un campo details sul model dell'utente ci puoi ficcare le specifiche che ti interessano

Nella tabella utente ci metti un campo "tecnico" si/no e poi decidi in base al campo se caricare i dettagli o no..
una soluzione più elegante sarebbe con un campo "type" cosi puoi distinguere gli utenti in più modi

quindi:

class userModel {

  protected $fields = array( 'id', ,'nome', 'cognome', 'details', 'type'  );
  public $details;
} 

la logica sarebbe

$mapper = new userMapper( $pdo );
$mapperTecnico = new tecnicoMapper( $pdo );

$user = $mapper->fetch( $id );

switch( $user->type ) {
  case 'tecnico':
    $user->details = $mapperTecnico->fetchByUser( $user->id );
    break;

  case 'banana':
    $user->details = 'banana';
    break;
}

print_r( $user ); 

in questo modo hai l'oggetto tecnicoModel all'interno dell'oggetto userModel
my2cents

[Fractals87]

Non mi è molto chiare il perchè non estendere la classe..
Negli esempi stupidi
Classe Mammifero
Classe Cane Extends Mammifero
Classe Delfino Extends Mammifero

Qui si evince il cencetto che il mammifero può essere un cane ma può non esserlo.
Entrambe le ipotesi sopracitate sono scorrette?

[satifal]

Anche secondo me non è concettualmente corretto estendere la classe utente in quanto, almeno logicamente, un utente può essere tecnico oppure no ma è una cosa non nota all'inizio. Se estendi la classe utente dovresti istanziare sempre oggetti di tipo tecnico pur non sependo se l'utente id lo sia o meno.
Credo che sia più corretto istanziare e caricare un utente che può eventualmente essere un tecnico. Quando fai il load di un utente tale classe utilizzerà un'istanza di tecnico al suo interno facendone a sua volta un load. A questo punto tu hai un'istanza di utente che fornisce anche i metodi di accesso all'istanza di tecnico.
Hibernate funziona allo stesso modo.

[Al_katraz984]

è diverso il discorso..

la classe tecnico è una integrazione della classe user

non per niente le tabelle come hai detto tu sono:

user
id|nome|cognome|password

tecnico
uid|campo1|campo2|campo3

che se ci pensi bene si possono scrivere anche:

user
id|nome|cognome|password|campo1|campo2|campo3

Quindi non si tratta di una estensione..

Se volessi gestire le due tabelle in modo separato e quindi identificare sia l'utente che il tecnico avrai

user
id|nome|cognome|password

tecnico
id|nome|cognome|password|campo1|campo2|campo3

anche qui nessuna estensione..

[satifal]

...anche qui nessuna estensione..

Quoto

Una relazione tra tabelle di un DB non può essere rappresentata mediante un'estensione.