validare form in modo scalabile e mantenibile

[Jardel]

Salve,
Ho necessità di trovare un modo elegante, scalabile e mantenibile per la validazione dei form. Per adesso mi sto muovendo con l'utilizzo di java puro e ovviamente delle servlets. Ho creato un mapping del mio database tramite diverse classi bean e stavo pensando di gestire la validazione dei form attraverso l'aggiunta di controlli nei vari metodi setter delle classi. Ad esempio se in un form bisogna inserire un nuovo utente si crea un'instanza della classe utente e si passano i vari dati ricevuti in input a una funzione di validazione che imposta i vari parametri attraverso i metodi setter i quali se si ha qualche problema vanno a impostare il relativo errore in un riferimento di variabile istanza a una un'eccezione appositamente implementata (potrei anhce definire una classe padre FormValidation con questi elementi)... in fine il metodo di validazione se c'è qualche problema solleva l'eccezione istanziata.

Il problema è che non so se il meccanismo sia troppo macchinoso e se alla lunga porti a più problemi che pro... cosa ne pensate? Secondo voi è un buon approccio? voi che approccio utilizzate?

[rsdpzed]

secondo me va quasi bene, ti do solo qualche consiglio (in realtà prendo spunto da come questa problematica viene gestita in diverse tecnologie .net).

- Innanzitutto eviterei di usare le eccezioni a questo livello. Gli errori di validazione provenienti da un form (e quindi dall'utente) dovrebbero portare a messaggi di errore per l'utente non al sollevamento di eccezioni.

- Non cadere nel facile tranello di associare le tue view direttamente alle classi che mappano il database. Io creerei un ulteriore modello oggetti che se pur simile a quello che mappa il database sia strettamente legato alle views (i tuoi form) e non al database e mi concentrerei su quello.

per esempio, riprendendo il tuo esempio, per validare il form di login non istanzierei l'entità Utente ma una creata apposta per quella form e cioè LoginVM (VM sta per viewmodel). Incidentalmente sia Utente che LoginVM saranno molto simili ma hanno responsabilità e ambiti molto diversi. I viewmodel puoi utilizzarli per molti altri scopi (legati allo stadio di interfaccia utente) non solo per la validazione.


Detto cio, crea un interfaccia (non una classe padre) costituita da un metodo Validate e una collection (magari una Dictionary) che conterrà l'elenco degli errori di validazione.

Ogni classe "viemodel" implementerà questa interfaccia. Quando ti arriva un form non devi far altro che mappare tutto sul relativo viewmodel e richiamare il metodo Validate.
Non ti resta che effettuare un check sulla Dictionary. Se la dictionary è vuota allora il form è correttamente validato altrimenti puoi rispedirlo indietro all'utente con tanto di messaggi di errore gia pronti nella dictionary.

- non mettere la logica di validazione nei metodi setter, centralizza tutto sul metodo validate. Magari durante l'implementazione del metodo, refattorizza tutto in diversi metodi private. So che puo sembrare anomalo rispetto a quello che ci hanno insegnato sui metodi setter ma serve per non sollevare eccezioni a questo stadio e avere l'opportunità di popolare la proprietà anche con dati non validi e continuare ad usare la classe viewmodel.


Idee per un miglior refactoring del metodo validate:

Anche qui non è farina 100% del mio sacco ma mi limito a riportare cio che hanno gia fatto in .net

Implementando i metodi validate ti accorgerai che alla fine della fiera le logiche di validazione sono sempre quelle 5 o 6: Validazione di uguaglianza, di Range, lunghezze massime o minime, campi obbligatori, match con regex...
Potresti implementare una classe per ognuna di queste logiche derivanti tutte da una classe astratta di base e relativo metodo IsValid(object valore).
Nel metodo Validate nei viewmodel per ogni proprietà da validare devi istanziare la giusta classe di validazione, settare i parametri (valore massimo, pattern regex, ecc.) e richiamare il metodo IsValid.

[Jardel]

ciao rsdpzed e grazie per i tuoi consigli, vedrò di applicarli anche se non capisco bene l'utilità di dividere i due moelli oggetti... non si rischia di avere troppa ridondanza?

[rsdpzed]

Perchè un utente e una form di login sono due cose diverse.

perchè istanziare una classe utente e lasciarla inconsistente con il solo scopo di effettuare la validazione a livello di una specifica form? se la validazione a livello di form è una responsabilità dello strato di presentazione perche inserire questa logica nelle entità?

Come gestisci logiche di validazione diverse che fanno capo ala stessa entità? Per esempio nella form di registrazione è necessario validare DUE campi password e controllare che questi siano uguali. Come fai? Utente ha solo una proprietà password mappata sul relativo campo del db! Aggiungi un campo all'entita? sporchi cosi l'entità utente per un motivo cosi circostanziato? dovresti avere piu metodi di validaione?
E ancora, come gestisci la validazione di un eventuale campo CAPTCHA? sarebbe a solo uso e consumo di un singolo form ma saresti costretto ad aggiungere anche questa ulteriore proprietà all'entita. Alla lunga guardando la classe Utente come fai a distinguere cosa è mappato sul db, cosa serve alla form di login, cosa alla form di registrazione e via dicendo?
L'entità utente diventerebbe troppo grossa e non sarebbe quasi mai in uno stato consistente.

Se un entità entra in gioco in diverse view (form, semplici liste per la visualizzazione, ecc) io creo un viewmodel per ogni view, qualsiasi operazione complessa riguardante i dati gestiti da quella view diventerebbe una responsabilità di un singolo viewmodel(*) lasciando alle entità mappate sul db compiti meno legati alla presentazione.
Posso dirti con certeza che la ridondanza qui è solo un falso problema, io in asp.net mvc non faccio altro che scrivere viewmodels

(*) non è proprio cosi, ci sarebbe un altro attore sulla scena ma tralasciamo altrimenti andiamo troppo offtopic. se vuoi approfondire cerca info su come implementare il pattern MVC in java (credo che sia Spring il framework in questione). Fermo restando che non è necessario adottare "per forza" il pattern MVC per parlare di quanto detto fin'ora.

[Jardel]

credo tu abbia ragione.... in definitiva non è consigliabile inserire la logica dei controlli all'interno del data model vero e proprio... questo mi fa pensare anche ai casi in cui si ha un form in cui interagiscono più componenti di due elementi del model differenti.. si sarebbe costretti ad instanziare le due classi e la logica dei controlli si perderebbe un pò tra le due istanze rendendo difficile la manutenibilità e riutilizabilità in quando una classe dipenderebbe dall'altra.

Ti ringrazio per i tuoi consigli... se passi vicino L'Aquila avanzi una birra gratis

[francesco.muia]

Tutto corretto quello detto finora chiamasi pattern MVC ed è un MUST per il web ma anche una gran cosa per lo sviluppatore che poi dovrà manutenere l'applicativo.
Secondo me validare lato server è alquanto dispendioso, quanto si può invece avere una validazione client.
Per esempio supponi di avere questo scenario:
L'utente inserisce le info, sbaglia 2 campi; invia la richiesta al server che gli da picche per i due errori.
L'utente risolve uno dei due errori e rinvia il form al server che gli darà di nuovo picche.
Magari i due errori sono del tipo il campo deve avere 3..4 caratteri.
Questo tipo di validazione io la farei direttamente sul client (javascript) in modo da dare errore all'utente prima di inviare la richiesta al server.
Ovviamente non è possibile validare tutto sul client, supponi di dover verificare che una mail sia presente già nella basi dati..., ma quello che si può validare sul client andrebbe fatto.
Anche lato javascript ci sono diversi modi per creare validazioni generali (per non parlare dei milioni di plugin di jquery).

Ciao

[Jardel]

Originariamente inviato da francesco.muia
Tutto corretto quello detto finora chiamasi pattern MVC ed è un MUST per il web ma anche una gran cosa per lo sviluppatore che poi dovrà manutenere l'applicativo.
Secondo me validare lato server è alquanto dispendioso, quanto si può invece avere una validazione client.
Per esempio supponi di avere questo scenario:
L'utente inserisce le info, sbaglia 2 campi; invia la richiesta al server che gli da picche per i due errori.
L'utente risolve uno dei due errori e rinvia il form al server che gli darà di nuovo picche.
Magari i due errori sono del tipo il campo deve avere 3..4 caratteri.
Questo tipo di validazione io la farei direttamente sul client (javascript) in modo da dare errore all'utente prima di inviare la richiesta al server.
Ovviamente non è possibile validare tutto sul client, supponi di dover verificare che una mail sia presente già nella basi dati..., ma quello che si può validare sul client andrebbe fatto.
Anche lato javascript ci sono diversi modi per creare validazioni generali (per non parlare dei milioni di plugin di jquery).

Ciao

Ciao,
Scusa se ti rispondo solo adesso... ovviamente hai ragione, la struttura è pesante. Quel che ho fatto però è stato definire tutti questi controlli lato server per poi replicarli anche lato client attraverso js. Tutto questo ovviamente per questioni di sicurezza.