Recentemente abbiamo avuto una discussione con i miei colleghi causata dal mio tentativo intenzionale di generare un messaggio user friendly sull'errore verificatosi (business logic) sul lato server.
Hanno insistito per mettere tutte le risorse stringa localizzabili all'interno dell'assembly del client Web e non quelle del server uno. L'argomento è lasciare che il cliente decida come generare e presentare messaggi all'utente. Non posso che essere d'accordo con l'esigenza di una tale flessibilità per i servizi pubblici, tuttavia sviluppiamo un sistema di back-office intranet e sviluppiamo anche parte client (sia thin che thick client). Francamente parlando il codice che ho visto finora non fa altro che generare il messaggio (identico al codice che ho provato a inserire in BL). Non ci sono controlli particolari che evidenziano popup precisi o qualcosa di simile. Ma ora la logica è duplicata: client web + win client.
Il mio punto è che è meglio aderire ai principi DRY e YAGNI. Copia incolla è malvagio.
Il secondo argomento è l'incapsulamento. Se si verifica un errore all'interno di Business Logic, è BL che sa come descrivere l'errore e quali informazioni aggiuntive devono essere raccolte e presentate all'utente senza compromettere la sicurezza o rivelare dettagli di implementazione alla parte client.
Ad esempio, in caso di modifiche simultanee restituiamo ConcurrenAccessError dal server e il client lo converte in "bla bla bla, l'oggetto è stato modificato da qualcun altro, modifica ancora una volta, per favore". Ora, per aggiungere il nome utente e il timestamp delle modifiche, ho bisogno di estendere ConcurrentAccessError class con proprietà aggiuntive e cambiare il codice di generazione del messaggio in due punti. Vorrei chiedere se il client dovrebbe anche conoscere la concorrenza come un tipo di errore speciale se non fa nulla al riguardo oltre alla notifica dell'utente. Il sistema non è progettato per la risoluzione dei conflitti tramite unione. Credo che l'elevata granularità degli errori sia importante solo quando tali informazioni strutturate consentono al sistema in qualche modo di aiutare l'utente a effettuare correzioni. (Il campo di input dell'email evidenziato e focalizzato è migliore di un semplice messaggio sotto il modulo)
Bene, alla fine non sono riuscito a convincere i miei colleghi. Ho dovuto seguire le convenzioni. Eppure ho bisogno di più argomenti pro e contro per continuare la discussione o concordare con loro.
Mi piacerebbe sapere quali strategie di notifica degli errori di solito usi e perché. Dove metti la logica della costruzione del messaggio?