Procedura consigliata per la convalida dei dati di input per l'applicazione multilivello

Question

Nella nostra applicazione abbiamo vari livelli. Service Layer, livello DAO e azioni (applicazioni struts).

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

Dove dovremmo idealmente mettere la convalida dell'input?

Dire, userid, il numero di telefono proviene da interfaccia utente, sono obbligatori. Quindi stiamo già facendo la validazione dal lato client.

Ora, secondo la mia opinione, tutto ciò di cui avete bisogno. No dove altro dovrebbe essere convalidato.

Ma uno dei miei colleghi sostiene, e se il cliente inoltra direttamente la richiesta. Quindi dobbiamo aggiungere anche azioni.

Ora, A Dao così, lo stesso metodo si sta abituando a qualche altra azione e tht non ha la convalida,

o, diciamo livello di servizio, potrebbe essere esposto come, dire come servizio web, Quindi c'è anche tu hai la convalida.

Quindi, in sostanza, sta suggerendo ... dovremmo avere convalide ovunque. Il che non ha senso per me. La sua duplicazione su più livelli.

Qual è l'approccio ideale per questo? Supponiamo che la validazione sia semplice controllo nullo o qualche convalida complessa.

Answer 1

D'accordo con Pangea, dovresti avere validazioni nel client e nel service endpoint.

Vorrei aggiungere che il concetto di convalida deve essere "fail-fast". Aggiungete le convalide a ciascun livello in modo che l'utente o il chiamante ottenga un riscontro immediato sul motivo per cui la chiamata fallirebbe invece di avviare potenzialmente una transazione, facendo query complesse e facendo una scrittura solo per scoprire che un campo è troppo breve.

Sul lato client, si desidera la massima convalida possibile in modo da non sprecare il tempo dell'utente, la larghezza di banda e le risorse lato server (che hanno in molti casi contese). Tuttavia, di solito non è possibile eseguire tutte le convalide sul lato client (ad esempio, per verificare se esiste già un nome utente in uso durante l'iscrizione), quindi è necessario verificarlo e un messaggio di errore corretto viene restituito non appena si colpisci il livello di servizio.

Sul livello server, si presuppone che tutti gli input siano potenzialmente pericolosi e non corretti (e spesso saranno i tempi). In realtà penso che sia meglio essere più completi e aggressivi sulla convalida degli input sul livello di servizio poiché questa è l'ultima linea di difesa. Se si omette una convalida o due sul lato client, è sufficiente un buon meccanismo di gestione degli errori per consentire agli utenti di sapere cosa c'è che non va. Se si dimentica qualcosa sul lato del servizio e disastri, potrebbe significare ore o giorni di debug e tentativi di ripristinare i backup del database.

Ci sono alcuni controlli che vengono eseguiti a livello di database e che fanno rispettare aspetti come l'integrità referenziale e così via. Di solito cerco il più possibile di controllarli prima di tentare una scrittura poiché interpretare i vari messaggi di errore di RDBMS e provare a convertirli in un gergo comprensibile all'utente è spesso difficile se non impossibile.

Answer 2

Se l'applicazione fornisce molteplici punti di ingresso (interfaccia utente o il sistema di interfacce di sistema o sistemi di lotti) allora si dovrebbe purificare (controlli nulli, assegni formato, richiesta-ness ecc) i dati a tutti questi bordi e prima raggiunge il livello di servizio. Ma questo non significa che è necessario replicare la logica di convalida. È possibile utilizzare framework che consentono di centralizzare la convalida. Alcuni esempi di framework di convalida possono essere trovati in questo post.

Tuttavia, esistono convalide aziendali che dovrebbero appartenere al livello del dominio e devono rimanere nel livello di servizio del dominio o negli oggetti del dominio.

Non sono d'accordo sul fatto che si dovrebbe eseguire la convalida in DAO. DAO dovrebbe essere solo responsabile delle operazioni CRUD. Se stanno facendo di più, hai strati che perdono. Se devi elaborare materiale in batch, devi assicurarti che il batch arrivi attraverso il livello di servizio in modo che anche il tuo batch abbia le stesse convalide.

Answer 3

L'unico elemento di saggezza che posso aggiungere alla conversazione è, non fidarsi mai del cliente. Sia che il tuo client sia in HTML, Flash/Flex, o qualsiasi altra cosa, c'è la possibilità che qualcuno lo hackerà e cercherà di fare qualcosa che tu non vorresti che facessero. Il follow up qui è, se c'è la possibilità che qualcuno lo hackerà, noi come ingegneri del software dobbiamo supporre che verrà hackerato, quindi mentre i controlli sul front end sono belli, e possono aiutare l'usabilità delle tue applicazioni , DEVI convalidare tutti i tuoi input sul back-end, anche se questo porta a controlli duplicati.