In un'applicazione Web supportata da un database, quanto spesso dovrei convalidare i dati? [duplicare]

Di solito quando l'ho fatto, l'ho fatto tutte e tre le volte, ma con una svolta che aggiunge valore a ogni livello:

• lato client : verifica la presenza di errori di dati talmente negativi da non essere mai inviati al server. Formattazione, una verifica della realtà leggera (per esempio - non c'è il 31 settembre).

• lato server : passaggio rapido della convalida dei dati, aggiunta di controlli di logica aziendale. A volte puoi persino riutilizzare lo stesso codice di convalida, quindi devi solo scriverlo una volta. A deve avere i controlli di tipo di sicurezza - iniezione, overflow, ecc.

• database - in genere, non ho utilizzato il database per lo stesso tipo di convalida dei dati. Ha una protezione minima contro le violazioni del formato e le violazioni delle dimensioni. Ma non tutti i controlli di qualità che il client e il server. Generalmente non presumo che il database non possa fidarsi del server. Il database dovrebbe controllare i dati da un punto di vista dell'integrità, tuttavia, ad esempio, il server non deve essere pubblicato in modo tale da avere operazioni di scrittura multiple, sovrapposte, in conflitto a causa della mancanza di aggiornamento dei dati.

Penso che puoi concentrarsi sul livello di convalida più vicino / più basso (server e database) a scapito dell'usabilità.

Approfondire la convalida del lato client tenendo conto dell'esperienza dell'utente.

La convalida del lato server dovrebbe preparare sufficientemente i dati per l'archiviazione nel database.

Usiamo Ruby on Rails e il pattern che si vede più spesso è quello di convalidare sul server e non molto altro.

Non puoi fidarti delle convalide lato client comunque. Almeno a noi qualche post in più non importa. Sebbene possano esserci situazioni in cui JavaScript può fornire migliori messaggi di errore. Ma non lo uso quasi mai per questo.

Quando il modello ha convalide e ci sono test che assicurano che tali convalide funzionino come previsto, non c'è ancora molto bisogno di convalidare nuovamente il database. Non solo non sarebbe DRY, dovresti aggiungere una logica extra nel tuo codice per gestire eventuali errori restituiti dal database. Errori che il modello avrebbe già dovuto generare.

Se non puoi "fidarti" del tuo codice, il tuo problema è il controllo di qualità, non dove posizionare (o ripetere) certe parti di esso. I test di unità corretti dovrebbero assicurarsi che tutto funzioni.

L'unica posizione che DEVI avere una convalida è nell'applicazione. Le convalide nel client sono, come dici tu, educate ma non necessarie. Le convalide nel database dovrebbero essere "databasey" - assicurando l'univocità delle chiavi univoche, ecc. - e possono essere impostate principalmente come parte delle definizioni delle tabelle.

Guardando dalla preoccupazione di DRY ... Non ci avevo mai pensato prima, ma potrebbe essere possibile usare le chiamate AJAX dal tuo javascript per eseguire routine di validazione sul server. Quindi è possibile riutilizzare le stesse routine nell'applicazione.

Se vuoi essere più DRY, puoi provare ad avere una forma di convalida dichiarativa da qualche parte (nel livello aziendale, ma le dichiarazioni possono essere solo in codice oppure puoi avere classi di metadati memorizzate in modo persistente) che è il base di tutto il codice di convalida. Probabilmente il codice di convalida sul client non corrisponderà esattamente al server (oltre a essere scritto in un'altra lingua), ma va bene. È ASCIUTTO se si inviano le dichiarazioni stesse al client da interpretare o se le si utilizza per generare un codice script java più specifico dal server.

Le regole di convalida del DB non possono essere realmente eseguite in questo modo a meno che tu non generi il database da un modello, e questo è più difficile di quanto valga.