Cosa restituire con i metodi CRUD Async

Dopo un sacco di ricerche in rete tanto quanto ho potuto, ecco i risultati finali che ho trovato sulla base delle mie ricerche.

Cose da evitare

• Evita di utilizzare il vuoto con i metodi asincroni. I voids non trasmettono eccezioni fino al metodo di chiamata che può portare a un codice asincrono difficile da debugare. (questo può essere mitigato, ma è ancora scoraggiato)
• Evita l'uso di booleani con il metodo di creazione / inserimento. restituire la chiave è altrettanto efficace se tutto ciò che ti interessa è se ha funzionato o meno, in più ci sono molte volte che avrai bisogno di quella chiave subito dopo la creazione / inserimento

Elementi da considerare

• Per tutti i metodi CRUD (ad eccezione della lettura) l'uso di un "oggetto risultato" o "oggetto facciata" può avere senso in base alla struttura. Se usi l'oggetto per scopi come la gestione degli errori, può essere utile, altrimenti probabilmente sarà solo uno spreco di tempo e risorse.

• Crea / Inserisci metodi per restituire il campo chiave è preferibile bool o void.

• I metodi di aggiornamento che restituiscono bool sono preferibili a key o void se l'aggiornamento è un metodo separato, se è un upsert trattarlo come un inserto.

• Cancella metodi restituire bool è preferibile a vuoto, la chiave va bene, ma spesso non sbaglia

• La lettura è un dato in esso dovrebbe restituire qualsiasi dato richiesto.

Opinione personale

Utilizza solo oggetti Result o Façade se li userai per cose come la gestione degli errori, altrimenti.

• Crea / Inserisci / Upsert: campo chiave
• Aggiornamento: booleano
• Elimina: booleano
• Leggi: dati richiesti

Potresti scoprire che alcuni metodi sono più comuni perché alcuni requisiti di salvataggio dei dati sono più comuni nelle applicazioni rispetto a qualsiasi tipo di standardizzazione. Non abbiamo controlli di errore perché è stato richiesto da alcune autorità di codifica, abbiamo i controlli di errore perché ci imbattiamo in problemi quando gli errori non vengono gestiti. "Ovviamente l'applicazione si è bloccata, hai inserito un valore nullo."

Essere coerenti è importante, ma ciò non significa fare tutto lo stesso. Questo dipende dai requisiti funzionali della tua applicazione. Differenziare ciò che è veramente diverso.

Esempio: Salva v. Salva & Chiudi

Ovviamente sono diversi, ma consideri la parte "Salva" della funzionalità come uguale? Se è così, entrambi fanno la stessa cosa nella parte Salva, e poi la chiusura. Che dire dal punto di vista dell'archiviazione dei dati? Sono uguali?

Se ho intenzione di salvare ed è un nuovo record, sarebbe conveniente restituire la chiave primaria / id appena generata dal database (supponendo che tutti i salvataggi lo facciano, cosa che potrebbero non farlo) in modo che l'applicazione possa attenersi a quel record e fare eventuali aggiornamenti, se necessario. Tuttavia, se sto andando a salvare e chiudere, restituisce l'ID: necessario, uno spreco di risorse o non diverso per tutti gli scopi pratici, quindi siamo coerenti con i nostri salvataggi.

Ci sono dei tempi (troppi) quando non abbiamo dati perfetti. Avrai ore di divertimento giocando "Chi ha cambiato il db?" Puoi decidere di fare in modo che l'applicazione verifichi che solo un record sia stato aggiornato e che venga lanciato un falso se non lo è. Forse la tua app non gestisce la concorrenza (che non accadrà mai) nel modo migliore, quindi hai appena aggiornato un record cancellato da un altro utente.

Restituisci le cose che ti servono quando ne hai bisogno. I requisiti cambieranno. Prova a decidere in anticipo se hai intenzione di lanciare le tue eccezioni, a nessuno piacciono le sorprese. Se le cose sono veramente le stesse, sii coerente, ma non provare a gestire requisiti diversi nello stesso modo.