Costante chiamate di database o archiviazione negli oggetti?

Is this good practice?

Si chiama Mappatura relazionale degli oggetti . ORM. È fatto tutto il tempo

Am I better off making one big call to the database and populating my objects and working with these objects, or should I retrieve data from the db only when needed?

Questo è imponderabile. Primo, non hai definito "migliore". Secondo, dipende dalla volatilità dei dati nel database, dalla natura dell'applicazione e dalle prestazioni del livello ORM.

Se il tuo dominio imita la struttura di base del tuo database, di solito è considerato una buona cosa; è facile rintracciare il recupero e la persistenza dei dati mentre si sposta tra i livelli di dati e dominio. La popolazione tramite stored proc o view può offuscare esattamente da dove proviene un determinato campo nel livello dati.

Per quanto riguarda la frequenza con cui popolare i dati, ciò dipende totalmente dalla tua applicazione. Più spesso si "sincronizzano" i dati tra l'app e il DB, più entrambi i lati sono aggiornati, TUTTAVIA, l'aumento della frequenza di trasferimento dei dati aumenterà il traffico di rete e l'utilizzo della CPU del server (il che potrebbe rendere il DB meno disponibile per altre richieste da altre app) e potrebbe ridurre la quantità di lavoro che può essere annullata (se si scrivono modifiche al DB immediatamente quando vengono apportate, invece di consentire all'utente di "commit" di tali modifiche, possono facilmente errore che va immediatamente al DB e colpisce altri utenti.

Se si tratta di un'applicazione basata sul Web, è necessario tenere presente il "paging" del set di risultati dei dati.

Ti consiglio vivamente di effettuare ricerche usando un qualche tipo di livello di astrazione dei dati. In Perl utilizzo Data :: ObjectDriver e / o Moose. Ogni lingua ha il suo equivalente. Ciò che questi framework forniscono è un modo semplice per definire le proprietà di un oggetto e quindi il framework gestirà l'interfaccia con il database. Spesso non è necessario creare le tabelle del database o scrivere una sola riga di codice SQL. Ciò non solo rende completamente inutile il compito banale di scrivere SQL per ciascuno dei tuoi oggetti, ma questi framework ti aiutano anche a risolvere altri problemi architettonici potenzialmente di grandi dimensioni, come il partizionamento del database e la memorizzazione nella cache.

Diamo un'occhiata a Data :: ObjectDriver come esempio, che seleziono solo perché ho esperienza nell'utilizzarlo. Gli esempi di codice sorgente forniti dalla relativa documentazione rendono chiara l'API: tu definisci un struttura dei dati e un database, e il framework creerà quindi le tabelle per fare interagire con una ricetta ad esempio semplice come:

my $recipe = Recipe->new;
$recipe->title('Banana Milkshake');
$recipe->save;

my $ingredient = Ingredient->new;
$ingredient->recipe_id($recipe->id);
$ingredient->name('Bananas');
$ingredient->quantity(5);
$ingredient->save;

Ora ecco un altro vantaggio dell'utilizzo di un framework come questo: una delle cose che Data :: ObjectDriver fa per te automaticamente è di interfacciarsi con un server memcached qualora fosse presente. Questo trasferisce automaticamente molto traffico dal database a un sistema di caching a bassa latenza sulla rete. Questa capacità e altre sono capacità che ottieni "gratis". E dal punto di vista dell'immagine, uno sviluppatore non dovrebbe mai preoccuparsi di reinventare la ruota, a meno che la ruota di cui si ha bisogno non sia stata ancora inventata. :)

Ora, torniamo alla tua domanda.

Am I better off making one big call to the database and populating my objects and working with these objects, or should I retrieve data from the db only when needed?

La mia risposta a questa domanda è quindi, non preoccuparti, ma solo se stai usando un buon livello di astrazione dei dati. Un buon livello di astrazione dei dati avrà già risolto molti problemi di scalabilità e sfide, o fornirà rimedi specifici per i problemi comuni che potresti incontrare.

Se trovi che devi scrivere questo codice da solo, allora mi sbaglierei dalla parte della semplicità. Mantieni semplici le query del database, anche se ciò significa richiedere più di esse per ogni richiesta specifica. Quindi utilizzare memcached per memorizzare nella cache i risultati della query. In questo modo, anche se occorrono 100 query per creare un singolo oggetto, allora così sia. La prima volta, genera le 100 query. Nelle richieste successive, non colpirai affatto il database.