Devo duplicare la convalida nel mio livello MVC e nel livello di servizio?

Question

Mi sento un po 'in conflitto al momento. Ho un'applicazione web che utilizza Stripes per un framework MVC e Spring/Hibernate per il back-end. Ho un metodo di registrazione dell'account nel mio strato di MVC che richiede la previa convalida:

• nome utente non è già preso
• L'indirizzo email fornito non è già associato a un altro account

Ho un metodo di validazione in Stripes (strato MVC) che controlla questi due casi ma si chiedeva se il mio livello di servizio dovesse duplicare questi controlli? Se l'interfaccia del livello di servizio è stata esposta come servizio Web, penso che la convalida sarebbe una buona idea, ma se è utilizzata solo nel contesto di un'applicazione web è necessaria?

Modifica: non intendo duplicare il codice di convalida, ovvero la duplicazione delle chiamate del metodo di convalida in due punti.

vedo le mie opzioni come:

1. Duplicare le chiamate di validazione sia MVC e livello di servizio
2. eseguire questa convalida solo nello strato di MVC
3. eseguire Solo questa convalida del livello di servizio.

Qual è la migliore pratica qui? Sto cercando consigli/opinioni su quale opzione dovrei andare e perché.

Si noti che esistono semplici controlli di convalida nei campi di input del modulo di registrazione (come il controllo degli spazi vuoti) e che penso che questi debbano essere gestiti solo dalla convalida MVC; Sono solo preoccupato per convalide più complesse.

Answer 1

Annie,

Buona domanda, ho chiesto io stesso lo stesso in molte occasioni. Ecco cosa ho finito (fino ad ora).

L'approccio più puro (ma noioso) è invocare la logica di convalida in entrambi i livelli. l'approccio pragmatico potrebbe essere quello di invocarlo solo in web-land (ad esempio i tuoi controllori).

Penso che non ci sia una risposta che termini tutta la discussione. Penso che dipenda dal contesto del tuo progetto. Se la dimensione del progetto è modesta (in termini di persone e dimensione della base di codice) e si è certi che non verrà sviluppato un intero lotto di codice da altri che invocano l'API del servizio (in misura tale da non essere in grado di sorvegliare), quindi solo la validazione nel livello Web può essere sufficiente.

Tuttavia, se si prevedono molti clienti, potrebbe essere necessaria una protezione di livello superiore. Quando dico sicurezza qui, mi riferisco ad esso come al livello di coerenza, garanzie di cui hai bisogno. Se questo livello è alto, non c'è modo di aggirarlo: lo si dovrà fare sia nel servizio (per sicurezza) che nel livello web (principalmente per essere in grado di fornire agli utenti finali un'esperienza accettabile).

Quindi il driver chiave qui è la sicurezza e quanta ne hai veramente bisogno. Se hai bisogno di molto, vai per l'approccio 'purista'. Se la tua domanda non prende esattamente decisioni che riguardano questioni di vita o di morte, vai per un approccio pragmatico.

Answer 2

Non duplicare il codice. Utilizza JSR303 Bean Validation in modo da poter utilizzare la stessa logica di convalida in tutti i livelli della tua app.

Hibernate Validator (un progetto separato dall'ORG Hibernate) fornisce l'implementazione di riferimento di questa interfaccia. È semplice da usare, puoi get started with it very quickly.

Answer 3

1. Idealmente, fare la convalida di entrambi gli strati, dal momento che il livello di servizio può essere utilizzato con un client diverso da quello corrente il livello MVC

2. riutilizzare il meccanismo di validazione in entrambi i posti (convalida Bean, per esempio)

Answer 4

a mio parere si dovrebbe diferenciate due tipi di convalide:

• La convalida dei dati del formato: che deve essere convalidata nel livello di presentazione (MVC nel tuo caso). Normalmente sia nel client e lato server
• bussines convalida dei dati: Quale dovrebbe essere convalidati nel livello di servizio

Nel tuo caso le vostre convalide sono legati a regole di business, così io li solo mettere in livello di servizio. Inoltre, se si duplicano le convalide in entrambi i livelli, si eseguiranno due volte le stesse query, rallentando le prestazioni dell'applicazione.