Recentemente ho iniziato a lavorare in un progetto enterprise java (~ 200 persone) che usa un client ricco SWT. In molti casi ho riscontrato che le regole aziendali non vengono convalidate sul lato server, perché i widget che attivano tali azioni sono disabilitati nel client SWT utilizzando le regole aziendali.
Questa è una questione ben nota di convalida in server, client o server + client e non sto indicando lo stesso problema. Inoltre, sono favorevole alla convalida in server + client.
La necessità di convalida nel client è ovvia perché consente un'applicazione più reattiva per l'utente finale e meno richieste per il server.
La necessità di convalida nel server è evidente con un client Web, in cui è possibile giocare con html e javascript per evitare le convalide sul lato client e inviare dati errati al server.
Ma con un client SWT questo non è così semplice (potrebbe essere ottenuto con uno sniffer di pacchetti come Wireshark?) quindi si potrebbe sostenere che la convalida nel server avrebbe un costo innescato in termini di prestazioni. Sempre in uno scenario in cui vi è un solo punto di accesso all'applicazione ed è il client SWT.
Se il progetto fosse iniziato ieri, mi batterò per la validazione server + client, ma in un progetto con 8 anni di storia questo potrebbe essere difficile perché dovremmo convincere gli utenti finali e gli analisti dei vantaggi della penalizzazione delle prestazioni.
Quindi, ogni volta che trovo uno di questi buchi di convalida, faccio fatica ad aggiungere la validazione lato server o lasciarlo andare, pensando "il client lo acchiapperà e questo non accadrà mai" e continuerò con un compito più prioritario.
Questo progetto è stato produttivo per quattro anni, quindi è una pratica praticabile, ma dal punto di vista del design, è corretto questo approccio? Aniway Penso che questa sia una conseguenza e non qualcosa di deliberatamente cercato.
Potrebbe essere preso come una decisione politica con conoscenza delle conseguenze o il mondo del software dirà NO a questa pratica?