Come dovrei progettare la classe per un'entità database?

1

Sto studiando OOP PHP e ho visto due tutorial che implementano il sistema di login e registrazione degli utenti come esempio. Ma l'implementazione varia. In che modo sarà più corretto lavorare con dati come questo?

  1. Carica tutti i dati recuperati dal database come array in una proprietà chiamata qualcosa come _data sulla creazione della classe e altri metodi operano con questa proprietà

  2. Crea proprietà separate per ogni campo recuperato dal database, durante la creazione della classe carica tutti i campi di dati in rispettive proprietà e gestisci separatamente tali proprietà?

Quindi diciamo che voglio creare un metodo che restituisca un elenco di tutti gli utenti con i loro dati. Qual è il modo migliore?

  1. Metodo che restituisce solo una serie di dati utente come questo:

    Array([0]=>array([id] => 1, [username] => 'John', ...), 
          [1]=>array([id] => 2, [username] => 'Jack', ...), 
          ...)
    
  2. Metodo che crea una nuova istanza della sua classe per ogni utente e restituisce una matrice di oggetti

posta Bakanyaka 21.11.2013 - 07:19
fonte

3 risposte

1

#2: Create separate properties for each field retrieved from database, on class creation load all data fields into respective properties and operate with that properties separately?

Questa seconda opzione (usando una classe) è lontano migliore a lungo termine. Un comune anti-pattern di PHP consiste nel passare tutto come matrici di valori-chiave, e alla fine diventa un enorme rompicoglioni. Avere un oggetto $this->__data privato è il primo passo verso il basso in questo percorso pericoloso.

Sarà molto più facile capire, eseguire il debug e refactoring, e come bonus l'IDE di solito può aiutarti a completare automaticamente le cose.

    
risposta data 09.08.2014 - 00:58
fonte
1

"Diciamo che voglio creare un metodo che restituisca un elenco di tutti gli utenti con i loro dati. Qual è il modo migliore?"

  1. Array : Questi saranno veloci, facili e semplici. Se si dispone di alcuni elementi in ciascun array, le cose saranno facili da tracciare e concentrarsi. per esempio. Saprai che l'indice 0 ha l'id utente, l'indice 1 ha il nome ecc. C'è una ragione per cui zend framework 2 usa matrici per la configurazione piuttosto che oggetti di grandi dimensioni. Per i bisogni di base questa è la strada da percorrere.

  2. Oggetti : Questi consumeranno più memoria e alla fine saranno (un po 'più) più lenti. Tuttavia, digita suggerimento se ne hai bisogno, e i nomi di fantasia dati ad ogni pezzo di dati sono il tuo vantaggio.

Il metodo " Miglior " dipende dalle tue esigenze. Probabilmente andrei con l'opzione 1 il più delle volte, dato che PHP è un linguaggio lento e mi piace che le cose siano veloci. Per i sistemi più complicati, utilizzerei doctrine.

    
risposta data 09.08.2014 - 17:25
fonte
0

Direi che entrambe le situazioni non sono appropriate:

  1. L'uso di matrici per rappresentare oggetti business non è una buona pratica. Il codice client deve conoscere la chiave esatta di ogni cella di matrice per indirizzare correttamente i dati. I metodi documentati focalizzati su ciascun campo dell'entità sono decisamente migliori per il codice client. Inoltre, a seconda delle dimensioni del database, potresti consumare molta memoria e la ricerca in questa struttura dati sarà lenta.
  2. Questo è meglio da una prospettiva OOP. Tuttavia, troverai gli stessi problemi di cui al punto 1. Come detto da Aal, un ORM (Object Relational Mapper) come Doctrine ti aiuterà a risolvere il consumo di memoria e a rallentare i problemi di ricerca (vedi sopra) perché gli ORM di solito implementano i linguaggi di query e tecniche di caricamento come il caricamento Lazy / Eager.

Per concludere, scegli un ORM, o qualcosa di vecchio stile, ma ancora valido in piccole applicazioni come i pattern Active Record o Data Access Object.

    
risposta data 10.01.2014 - 13:49
fonte

Leggi altre domande sui tag