L'implementazione OOP ha dei dubbi con i database

Question

L'implementazione OOP ha dei dubbi con i database

#1 da (4 voti)
#2 da (3 voti)
#3 da (0 voti)

1

Stavo iniziando un progetto oggi e, dopo aver progettato la struttura del database e il modo in cui i dati sarebbero stati archiviati, ho iniziato l'implementazione. Lo sto facendo su php, ma qui il linguaggio non è rilevante, dato che i miei dubbi sono più legati all'architettura o immagino, dal momento che sto lottando più di quanto pensassi implorando cose in OOP su PHP. (Recentemente sono passato su PHP, ho scritto codice in c ++ e java prima).

Quindi, ho iniziato creando la mia classe "Utente", semplice, pochi attributi e __costruire, inserire, aggiornare ed eliminare metodi. Quelli ultimi 3, domande al db.

Quindi questo dubbio mi è venuto alla testa, e probabilmente conosco la risposta da solo ma non lo so.

Ora posso creare istanze e creare nuovi utenti: $ user = new User ("John", 34) ma, cosa succede se voglio modificare l'utente "Dave"? O voglio mostrare tutti gli utenti. Questo metodo, ad esempio, getAllUsers () restituirebbe tutti gli utenti in cui verrebbero implementati? Perché in realtà non appartiene alla classe Utente giusto? Se lo facesse, allora come dovrei istanziare quel metodo se non ho alcuna istanza Utente?

Credo che avrei bisogno di una classe Users o UserCollection che sarebbe una raccolta di tutti gli utenti, con i metodi'getCertainUser (id) 'e'getAllUsers ()' che restituirebbero determinati utenti o tutti loro, ora poi avrei un utente che sarei in grado di modificare. Questo è il modo in cui ho fatto sia in Java che in C ++, dato che non ho usato un database per archiviare i dati, è stato memorizzato su un Set / Mappa o qualunque sia la struttura, e quindi salvato su file.

Detto questo, le mie domande sono: come dovrebbe essere affrontato questo problema come strada da percorrere, sto complicando troppo le cose? Come questo dovrebbe essere risolto 'nel modo corretto' in OOP. Le volte in cui ho gestito problemi simili non ho mai usato un database, quindi avere un gruppo di utenti era l'unico modo per memorizzarli, ma avere il database che memorizza gli utenti si sente ridondante per avere quella raccolta di utenti.

Grazie in anticipo.

object-oriented database php class

posta ruuux93 05.03.2015 - 21:44

fonte

3 risposte

Leggi altre domande sui tag object-oriented database php class

Come funziona la comunicazione tra un server di chat e un client? Il livello di granularità per ripetere il codice: il download, la decompressione, ecc. devono essere gestiti da classi separate?

score 4 · Answer 1

Se stai cercando "il modo corretto" per sposare il codice orientato agli oggetti con la persistenza del Database relazionale, sarai profondamente deluso. Non esiste un singolo "modo corretto", solo un intervallo di opzioni.

Alcuni consiglierebbero di separare le tue preoccupazioni (come suggerito da AvetisG in la sua risposta ), inserendo la logica di business in una logica di classe e persistenza in un'altra. Un esempio di questo, utilizzando il modello di repository, è fornito in questa domanda / risposta SO .

Gli altri si sentono perfettamente a loro agio combinando tutte le cose relative all'Utente, inclusa la persistenza, nello stesso oggetto. Un esempio di questo è il pattern Record attivo .

Ti suggerirei di familiarizzare con queste alternative, e poi andare con ciò che ha più senso per te. Alla fine, sarà il modo più corretto.

score 3 · Answer 2

Il problema dovrebbe essere risolto separando le preoccupazioni

Ecco cosa intendo.

Il motivo per cui hai una brutta sensazione nell'aggiungere getAllUsers () alla classe User è perché è troppa responsabilità per quella classe . Ciò potrebbe sconvolgere le cose, specialmente quando si tenta di testare le cose.

Il mio suggerimento sarebbe ripensare il modo in cui lo stai facendo.

Invece di rendere la classe User a conoscenza di tutte queste cose, come l'inserimento di se stessa, l'aggiornamento stesso e magari la restituzione di tutti gli utenti, renderlo invece un oggetto DTO che non sa nulla.

Quindi disponi di un UserManager che acquisisce quel DTO che può inserirlo nel database, aggiornarlo, eliminarlo e avere un UserReader o UserRetriever (o un altro nome che ottiene il punto) che restituisce tutti gli utenti come elenco di DTO o un utente specifico in base all'ID.

In questo modo rende il test più facile e ha senso concettualmente che è fondamentale quando - vuoi che gli altri contribuiscano al progetto o semplicemente mantenerlo da solo.

score 0 · Answer 3

I database relazionali si occupano di insiemi. Se vuoi implementazioni OO flessibili e utilizzabili, anche le tue classi dovrebbero essere set ie. collezioni.

Quindi hai una classe "Users" che è una collezione di classi "User".

Devi supportare i seguenti metodi: -

   Users.loadById(id)   // get one user from db
   Users.loadAll()      // definately not scalable !
   Users.loadWithFilter("sql where clause") 

   Users.first()       // first user in result set
   Users.next()        // next user in result set
   Users.byId(id)      // search for specific user id in current set

   Users.Update(id)    // make changes persistant in db for an indvidual entry
   Users.Delete(id)    // delete individual user from db
   Users.New(User)     // Insert new user into database.

Quindi tutta la gestione SQL è nella classe Users, la classe User contiene solo i valori della colonna.