Argomenti contro creare o aggiornare

Question

Recentemente qualcuno ha dichiarato che hanno pensato tutti Crea dovrebbe essere CreateOrUpdates. Istintivamente ho pensato male, ma ora sto cercando di scoprire se ho motivi.

Situazione

interface IService{ 
    void Create(Object a); 
    void Update(Object a); 
    } 

o

interface IService{ 
     void CreateOrUpdate(Object a); 
    } 

Il mio primo pensiero è che se è stato implementato tutto ciò CreateOrUpdate allora si ha alcun controllo se qualcuno accidentalmente si invia i dati sbagliati, o problemi di concorrenza in cui qualcuno cambia un " campo primario" giusto prima di chiamare update ....

Ma se si rimuove questi casi, ci sono altri svantaggi?

Answer 1

Mi sembra abbastanza semplice: se si è preoccupati della creazione di record accidentale, utilizzare i due metodi. Se non sei preoccupato, usane uno.

E se non si sa se si dovrebbe essere interessato o no, si arent interessati. Vai con un metodo.

Forse è troppo semplicistico, ma in genere l'obiettivo è solo quello di ottenere i dati nel database.

Answer 2

Nel quadro che usiamo, non c'è Creare, solo CreateOrUpdate. Non abbiamo mai incontrato un caso in cui avevamo bisogno solo di creare.

In altre parole, è quello che è stato offerto, quindi siamo andati con esso, e non ci ha ancora fallito. Il sistema ha due anni con circa 300 tavoli.

Nel nostro caso, non cambiamo le chiavi primarie, e se la chiave primaria corrisponde a una riga esistente, non è sbagliato.

Answer 3

Una volta ho lavorato a un'applicazione di reporting finanziario in cui gli aggiornamenti erano vietati, tutte le modifiche erano la creazione di nuovi record con dati aggiornati. Questo era per fornire una cronologia completa delle revisioni di tutte le modifiche all'account.