Valori del valore di proprietà su entità POCO

Se esiste un'applicazione client, normalmente non si esegue alcuna convalida dei dati nel database a meno che ciò non provochi un errore nel database ad es. NULL quando era previsto un valore.

Se esiste un intervallo di valori validi, tuttavia, non è raro archiviarli nel database e renderli disponibili all'applicazione client. Questo è talvolta noto come metadata .

Per la cintura e le graffe codifica difensiva , suona come avere la convalida dei dati in più luoghi è una buona idea, ma se vuoi cambiare questo, dovresti aggiornare la logica in entrambi i posti. La validazione è posizionata al meglio in un singolo livello (ad esempio unica fonte di verità ) piuttosto che sparsa per tutta la soluzione.

Se la tua convalida viene eseguita a livello di database, stai lavorando attraverso strati di codice per arrivarci. È costoso, perché trasmettere solo i dati per scoprire che è sbagliato? È possibile che si stiano aprendo transazioni inutili a lungo termine che influiscono su ogni utente dell'applicazione. Non solo, ma la convalida SQL è molto meno flessibile di quello che puoi fare in JS / C # o in uno qualsiasi degli altri linguaggi disponibili.

Suggerirei di convalidare il più in alto possibile, in quanto è possibile / sensato (ovviamente se hai più UI non lo scrivi più volte). L'interfaccia utente è buona, gli oggetti dominio sono buoni (anche se mi piace tenerli come pocos), la BLL è comune.

Ovunque lo metti, assicurati di essere coerente in modo da poterlo trovare più tardi!

Personalmente preferisco diffondere convalide su livelli basati su un ambito ben definito.

1. Database
   Queste serie di convalide potrebbero essere imposte in base a vincoli. Questi NON dovrebbero essere nuovamente convalidati in nessun livello con alcune eccezioni. Esempio UNIQUE , NOT NULL , Lunghezza massima, Tipo di dati ecc. Il database non accetterà i dati che non soddisfano il vincolo. Convalida di nuovo in alcuni livelli è inutile nella maggior parte dei casi.
   L'interfaccia utente può ripetere alcune di queste convalide in base a necessità come controllo nullo, univocità se tutti i dati sono già disponibili nell'interfaccia utente. Per verificare l'univocità nel caso in cui tutti i dati non siano disponibili nell'interfaccia utente, l'unico modo è effettuare una chiamata al database. Invece, lascia che il database generi un'eccezione. Ogni modo costa lo stesso. Invece di scrivere il codice, la validazione della lunghezza può essere imposta impostando la proprietà di controllo della lunghezza massima.

2. Servizio (BLL)
   Potremmo avere alcune regole aziendali che dovrebbero essere seguite dall'entità. Esempio, la mia domanda si aspetta il peso della persona in cifre solo in unità di chilogrammo. Quindi i valori validi sono solo in formato "000.000". Non preferisco far rispettare questo lato del database. Preferisco farlo in servizio. Altro esempio è il genere persona dovrebbe essere M o F per la mia applicazione. Nel database, questo è CHAR (1) . Ancora una volta, preferisco gestire questo in livello di servizio invece di database. L'interfaccia utente generalmente non gestisce affatto questo. Semplicemente sceglie i controlli per ottenere correttamente gli input. La casella combinata oi pulsanti di opzione per il sesso sono buoni; non è necessario scrivere codice aggiuntivo.

3. Interfaccia utente (applicazione)
   Tutto ciò che non rientra in due potrebbe adattarsi qui. Buona parte di queste convalide dovrebbe essere gestita attraverso la corretta scelta dei controlli.