Regole aziendali, logica aziendale, convalida dell'input

Sei sulla strada giusta. La logica di convalida del dominio o dell'attività commerciale deve fare molto di più del semplice rapporto vero o falso. Vuoi abilitare l'utente delle tue classi di business (ad esempio l'interfaccia utente o il tuo sistema di registrazione) per fare qualcosa di più che segnalare all'utilizzatore che qualcosa non va.

Ora, come lo fai è completamente a te.

Decisione da fare: controlla tutto e quindi segnala tutti gli errori / avvertimenti / informazioni o fermati al primo che incontri. Personalmente, opterei per il primo e consentirò all'interfaccia utente di decidere come utilizzare le informazioni. Esiste comunque un compromesso: alcune convalide potrebbero richiedere più tempo di altre e potresti volerle controllare solo se le "semplici" riescono.

In ogni caso non utilizzerei eccezioni per farlo. Alcune persone usano eccezioni perché la maggior parte degli ambienti di sviluppo ha un buon modo di mostrare le eccezioni non gestite all'utente. Penso che sia solo una scelta cattiva / pigra. E non solo perché è difficile decidere da dove viene l'errore (anche se le tracce dello stack possono esserci d'aiuto), ma anche perché può (volere) lasciare l'app in uno stato imprevedibile e può causare errori in futuro. ancora più difficile da eseguire il debug.

Pertanto, tendo a riservare eccezioni per circostanze eccezionali. Cose che non avevo previsto. A mio avviso, la convalida non rientra in questa categoria: hai previsto tutti i problemi di convalida (attuali) o non li avresti convalidati.

Tutto sommato, codifico la convalida nelle classi dominio / business per raccogliere un array (o qualsiasi cosa mi interessi di usare) delle istanze di errore / avvertimento / suggerimento. Possono essere stringhe semplici, possono essere classi complete. Di solito restituisco sempre un'istanza al chiamante e mai un puntatore non assegnato. "Valido" è semplicemente indicato da un numero di messaggi pari a zero.

I read that some people use exceptions.

C'è una ragione per cui. Le eccezioni gestiscono le situazioni eccezionali molto bene. Se la tua lingua ha delle eccezioni, inizia a usarle.

I dati non validi dovrebbero generare un'eccezione.

L'applicazione può quindi raccogliere tutte le eccezioni di convalida dei dati e visualizzarle all'utente.

I've thought that I could return error messages and when everything goes fine then it would be null.

Una funzione che restituisce un valore appropriato o che a volte restituisce un valore di "stato" (riga null ) è una cattiva idea. Una funzione dovrebbe sempre restituire un valore appropriato o generare un'eccezione.

Somehow error codes just don't add up for me.

Questo perché i "codici" di errore sono una pessima idea. Tranne che nei programmi C in cui hai pochissima scelta.

PPPHP,

Hai letto: Domain Driven Design ? Questo libro ha materiale abbastanza buono sullo sviluppo di buoni modelli di dominio per l'isolamento delle regole di business.

Quando correggi bug nei progetti, tendo a scrivere una user story per quella parte di funzionalità per capire come funziona dal punto di vista degli utenti. Ad esempio, ieri, stavo correggendo un bug che causava un IllegalArgumentException se una certa casella combinata non è stata popolata con i dati richiesti. L'utente dovrebbe ripristinare il dispositivo e riavviarlo. Ora, risolvere questo problema può sembrare ovvio, ma la storia dell'utente ha contribuito a chiarire il mio modo di pensare. Ho finito per pacificare quella particolare eccezione e assicurarmi che la casella combinata avesse il testo "dati non disponibili". Quindi, quando l'utente solleva un bug o chiama il supporto, il problema viene compreso meglio e al cliente non è stato lasciato alcun messaggio di errore oscuro. Piccole modifiche come questa sembrano fare una grande differenza quando si tratta di clienti.

Di solito uso sia un flag di successo che un elenco di messaggi, ognuno dei quali comprende sia un codice che un messaggio a mano libera. Se ricevi una risposta positiva con i messaggi, sai che i messaggi sono tutti avvisi e che qualcosa è successo sul lato server.

Il motivo dell'utilizzo di entrambi i codici e messaggi è che un messaggio può essere visualizzato da un lettore umano ma un codice può essere gestito dal software. In questo modo, se il messaggio a forma libera cambia, anche il software che gestisce quell'errore non deve cambiare.

Ovviamente se sei sicuro che non ci sarà mai un lettore non umano delle tue risposte, puoi dimenticare i codici, ma è una decisione difficile da annullare in seguito.