DAL dovrebbe verificare la presenza di oggetti prima di creare o aggiornare

Questa è una decisione architettonica classica. Avrai voglia di guardare i pro e amp; svantaggi di ciascun approccio e prendere la decisione migliore per i consumatori del sistema.

Il vantaggio dell'approccio Save / Upsert è che semplifica l'API. Molti sistemi lo fanno, incluso Salesforce.com.

Ma , se il consumatore sa (per quanto possibile) che un record è nuovo di zecca, è più efficiente fare un Crea / Inserisci senza prima applicare un blocco e verificare l'esistenza.

(Anche se il tuo database potrebbe essere ottimizzato per Save / Upsert - ti consigliamo di prenderlo anche tu.)

Infine, ti consigliamo di pensare al comportamento concorrente che stai esponendo al consumatore. Ad esempio, se il consumatore crede che stia aggiungendo un nuovo record, ma in realtà un altro utente è scivolato in avanti e ha creato il record, è ok per aggiornare in modo silenzioso il record? O è meglio restituire un errore grave ("il record esiste già")?

I vincoli di dati come l'unicità possono essere applicati solo dal server del database stesso. Da solo implementa le serrature e altre proprietà ACID necessarie per risolvere questo problema, che incidentalmente è un controllo della concorrenza problema.

Per far sì che tutto funzioni, puoi gestirlo in stored procedure o, se sei fortunato, puoi configurare / programmare il tuo Data Access Layer in modo che lo faccia per te. Se il DAL lo fa, sarà comunque necessario creare una transazione di database, ma può occuparsi dei dettagli di implementazione.

Il livello aziendale non può farlo perché non sa come costruire il giusto tipo di transazione per impedire agli utenti concorrenti di interferire con la tua regola di unicità. Puoi ancora eseguire un controllo preliminare, ma devi anche gestire il tipo di eccezione che potrebbe essere sollevata se l'oggetto viene inserito da qualcun altro nel tempo stretto tra il controllo e l'inserimento.