Qual è un modello di progettazione migliore per un wrapper di database: Salva come vai o Salva quando hai finito?

Question

Qual è un modello di progettazione migliore per un wrapper di database: Salva come vai o Salva quando hai finito?

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

5

So che probabilmente è un brutto modo di fare questa domanda. Non sono stato in grado di trovare un'altra domanda che ha risolto questo problema.

La domanda completa è questa: stiamo producendo un wrapper per un database e abbiamo due diversi punti di vista sulla gestione dei dati con il wrapper.

Il primo è che tutte le modifiche apportate a un oggetto dati nel codice devono essere mantenute nel database chiamando un metodo "salva" per salvare effettivamente le modifiche. L'altro lato è che questi cambiamenti dovrebbero essere salvati così come sono fatti, quindi se cambio una proprietà è salvata, ne cambio un'altra è anche salvata.

Quali sono i pro / contro di entrambe le opzioni e quale è il modo "corretto" per gestire i dati?

Per fornire maggiori informazioni, stiamo utilizzando Node.js e stiamo scrivendo il nostro wrapper per Neo4j perché riteniamo che quello attuale non sia completo o che abbia incontrato problemi in cui abbiamo bisogno di più funzionalità. Detto questo, un esempio del metodo save as you go (questi esempi sono in Javascript):

// DB is defined as a connection to the database via HTTP(REST)
// "data" being an object that would represent new data
var node;
db.getNodeById(data.id, function(err, result) {
  node = result;
  // This function task an optional callback as a third parameter because in
  // in addition to setting the property on the "node" object it saves the
  // new value to the database by making an HTTP request.
  node.set("firstName", data.newFirstName);
  // auto saved as well
  node.set("lastName", data.newLastName);
  // end here as the node has already been updated with your changes.
});

E l'esempio opposto sarebbe:

// DB is defined as a connection to the database via HTTP(REST)
// "data" being an object that would represent new data
var node;
db.getNodeById(data.id, function(err, result) {
  node = result;
  // This changes the value for the node object only, nothing in the
  // database is changed.
  node.set("firstName", data.newFirstName);
  node.set("lastName", data.newLastName);
  // Save all your changes
  node.save();
});

database design-patterns

posta izuriel 04.04.2012 - 01:22

fonte

3 risposte

3

Vado per chiamare esplicitamente il metodo save (). Altrimenti riceverai salvataggi ridondanti quando non ne hai bisogno. Che cosa succede se si dispone di una sorta di evento "onKeyUp". Vuoi davvero salvare come l'utente sta digitando ogni personaggio? Saresti rinchiuso in quel modello.

In un'app a più livelli è utile che il codice sia "consapevole" del livello su cui è attivo. Non è necessario nasconderlo avendo dietro le quinte un sacco di magia salvifica dello stato. Perché essere "consapevoli" è buono? Perché nasconderlo sta offuscando il suo funzionamento, non astrazione. (la mia opinione).

Su un altro argomento ... invece di Node.save (); usa save (Node n); In realtà il salvataggio potrebbe comunque essere un metodo di un oggetto, ma non l'oggetto Nodo. Perché? Il salvataggio non è qualcosa che fa un nodo. E questa funzionalità è letteralmente diversa a seconda del tuo livello, suggerendo che si tratta di un comportamento del livello, non del nodo.

Per esempio, diciamo che hai Node.Draw (); Questo metodo non ha nemmeno senso sul lato server. Invece fai qualcosa come GameBoard.Draw (Node n);

Probabilmente sto andando troppo lontano dal tema, ma questo è il mio 2 centesimi.

risposta data 04.04.2012 - 02:58

fonte

0

Questo post è vecchio, ma ho avuto lo stesso problema per quanto riguarda un progetto di gestione delle scorte che la mia azienda sta costruendo. È un'applicazione PHP basata sul Web con un backend PostgreSQL. Abbiamo optato per l'approccio Save-As-You-Go rispetto allo stile Stage-and-Commit (ho preso in prestito i termini dal controllo di versione perché è accurato qui), perché vogliamo offrire un feedback immediato all'utente se c'è un problema salvare un aggiornamento del record nel database attuale. Attendere fino alla chiusura dello script e chiamare i distruttori per scoprire finalmente che c'è un problema con il salvataggio di tutte le modifiche dell'utente era un rischio inaccettabile (data la complessità che le nostre transazioni possono avere). Lo svantaggio potrebbe essere un aumento del traffico del database, ma l'utente può sapere anziché sperare che le sue modifiche siano state eseguite correttamente. Questi sono i pro e i contro che ho preso in considerazione quando ho risposto a questa domanda per conto mio. Spero che la mia risposta aiuti anche qualcun altro.

risposta data 30.08.2016 - 18:43

fonte

Leggi altre domande sui tag database design-patterns

Programmi di controllo della versione per file XML - strumento di unione / diff L'assunzione di uno sviluppatore junior come istruttore tecnico è una buona idea?

score 7 · Accepted Answer

Se hai bisogno di transazioni nella tua applicazione, dovrai offrire qualche tipo di opzione "Salva" esplicita. Se le applicazioni non hanno bisogno di transazioni, l'uso di un database (al contrario, ad esempio, di una tecnologia NoSQL) potrebbe essere ridondante.

Questo significa anche che l'operazione "Salva" non dovrebbe essere un metodo chiamato sull'oggetto mutato. Dovrebbe essere un metodo sull'oggetto transazione o sulla sessione.