Best practice per la convalida dei dati di input per l'applicazione multi-livello [chiuso

Question

Nella nostra applicazione abbiamo vari livelli. Livello di servizio, livello DAO e azioni (applicazioni Struts).

I dati vengono passati da un livello a un altro livello.

Dove dovremmo idealmente inserire la convalida dell'input?

Ad esempio, UserId, il numero di telefono proviene dall'interfaccia utente, sono obbligatori. Quindi stiamo già facendo la convalida sul lato client.

Ora, secondo la mia opinione, tutto ciò di cui hai bisogno. In nessun luogo dovrebbe essere convalidato.

Ma uno dei miei collega sostiene, cosa succede se il cliente effettua la richiesta direttamente. Quindi dobbiamo anche aggiungere azioni.

Ora, anche su DAO, lo stesso metodo si sta utilizzando in qualche altra azione e non ha convalida,

Oppure, diciamo il livello di servizio, potrebbe essere esposto come, diciamo come servizio web, quindi anche lì hai convalida.

Quindi, essenzialmente, sta suggerendo ... Shd abbiamo validazioni ovunque. Il che non ha senso per me. La sua duplicazione attraverso lo strato.

Qual è l'approccio ideale per questo? Supponiamo che la convalida può essere un semplice controllo nullo o una convalida complessa.

Answer 1

D'accordo con Pangea, dovresti sicuramente avere convalide negli endpoint del cliente e del servizio.

Vorrei aggiungere che il concetto di convalida deve essere "fallito". Aggiungi validazioni a ciascun livello in modo che l'utente o il chiamante ricevano un feedback immediato sul perché la chiamata fallirebbe invece di avviare potenzialmente una transazione, fare query complesse e scrivere solo per scoprire che un campo è troppo breve.

Sul lato client, si desidera il maggior numero possibile di convalida in modo da non perdere tempo, larghezza di banda e risorse sul lato server (che hanno contese in molti casi). Tuttavia, di solito non è possibile eseguire tutte le convalide sul lato del client (ad esempio, per verificare se esiste già un tale nome utente in uso sulla registrazione), quindi vorresti che il messaggio di errore controllato e corretto non appena si è riportato Colpisci il livello di servizio.

Sul livello del server, si desidera presumere che tutti gli input siano potenzialmente pericolosi e errati (e spesso lo saranno). In realtà penso che sia meglio essere più completi e aggressivi per convalidare gli input sul livello di servizio poiché questa è la tua ultima linea di difesa. Se lasci fuori una convalida o due sul lato client, hai solo bisogno di un bel meccanismo di gestione degli errori per far sapere agli utenti cosa c'è che non va. Se perdi qualcosa sul lato del servizio e gli scioperi dei disastri, potrebbe significare ore o giorni di debug e cercare di ripristinare i backup del database.

Ci sono anche alcuni controlli che vengono eseguiti a livello di database che applicano cose come l'integrità referenziale e simili. Di solito cerco il più possibile di verificarli prima di tentare una scrittura poiché interpretare i vari messaggi di errore di RDBMS e provare a convertirli al gergo comprensibile dell'utente è spesso difficile se non impossibile.

Answer 2

Se l'applicazione fornisce più punti di iscrizione (interfaccia utente o sistema alle interfacce di sistema o sistemi batch), è necessario purificare (Controlli null, controlli in formato, richiesto ecc.) I tuoi dati a tutti questi bordi e prima che raggiungano il livello di servizio. Ma questo non significa che devi replicare la logica di convalida. Puoi usare framework che ti consentono di centralizzare la tua convalida. Alcuni framework di validazione di esempio sono disponibili in questo inviare.

Tuttavia, ci sono validazioni aziendali che dovrebbero appartenere al livello del tuo dominio e dovrebbero rimanere nel livello di servizio di dominio o negli oggetti di dominio.

Non sono d'accordo sul fatto che dovresti eseguire la convalida in Dao. Dao's dovrebbe essere solo responsabile delle operazioni CRUD. Se stanno facendo di più, hai strati che perdono. Se devi elaborare le cose in batch, dovresti assicurarti che il batch arrivi attraverso il livello di servizio in modo che anche il tuo batch stia attraversando le stesse validazioni.

Answer 3

L'unico pezzo di saggezza che posso aggiungere alla conversazione è, non fidarti mai del cliente. Che il tuo cliente sia in HTML, Flash/Flex o altro, c'è la possibilità che qualcuno lo hackerarà e proverà a fare qualcosa che non vuoi che facciano. Il seguito qui è che se c'è la possibilità che qualcuno lo hackerarà, noi ingegneri del software dobbiamo supporre che verrà hackerato, quindi mentre i controlli sul front -end sono belli e possiamo aiutare nelle tue applicazioni usability , devi convalidare tutti i tuoi input sul back -end, anche se ciò porta a controlli duplicati.