Va bene mettere tutta la gestione degli errori sul layer facciata?

Question

Va bene mettere tutta la gestione degli errori sul layer facciata?

#1 da (2 voti)
#2 da (0 voti)

1

Sto facendo un progetto di backend Java Spring-Boot e sto implementando un pattern controller-facade-service sulla mia struttura.

Quindi è meglio mettere tutta la mia gestione degli errori sul livello facciata, mentre il servizio lancia solo gli errori e il controller riceve solo l'entità di risposta prodotta dalla facciata?

Lo immagino in questo modo perché la facciata sarà l'unico posto in cui chiudere ResponseEntity, se si tratta di un errore o di una chiamata riuscita, lasciando anche al controller un codice più pulito, solo per le chiamate e le risposte ricevute.

error-handling java spring project-structure facade

posta djrumix123 03.07.2018 - 14:11

fonte

2 risposte

Leggi altre domande sui tag error-handling java spring project-structure facade

Perplesso per principio di dipendenza dalla dipendenza: cosa succede se è dipendente dal runtime quali oggetti vengono creati? Uso del pattern Builder per standardizzare i dati di restituzione

score 2 · Answer 1

No, non va bene. Una facciata può semplificare l'interfaccia o essere utilizzata solo per rendere pubblici metodi specifici, ma concettualmente, pensare a una facciata come una lente. Dovrebbe fungere da ponte tra le parti del tuo programma, ma probabilmente non vorrai mai gestire gli errori in uno, perché gli errori che vengono restituiti sono molto importanti.

Detto questo, sei incoraggiato a catturare e rilanciare o catturare simili eccezioni e ripensare a un altro. Sebbene tu non voglia, ad esempio, catturare tutti gli errori, quindi restituire null perché null può essere una risposta legittima dalla tua classe.

Certo, forse sai il metodo non restituirebbe mai null e quindi restituire nulll nella tua facciata potrebbe essere trattato come un errore, ma una facciata non dovrebbe fare tali considerazioni quando è molto dipendente dal reale implementazione di detto metodo chiamato. Se dovessi cambiare in futuro, sarà un bug difficile da trovare.

score 0 · Answer 2

Lo scopo della facciata è un intermediario. In realtà non fa nulla da sé. Qualsiasi metodo ha solo il suo scopo come ponte tra due cose (controller e servizio in questo esempio). Quindi, come esempio stupido, forse il servizio accetta due argomenti sotto forma di nome e cognome, ma la facciata richiederà un singolo argomento dal controller sotto forma di nome completo. L'unico lavoro che fa la facciata è rompere il singolo argomento nei pezzi che il servizio si aspetta.

Ma Error Handling richiede una logica più sofisticata, e metterla nella facciata avrebbe la facciata fare qualcosa. La facciata potrebbe sentire l'errore o gli errori dal servizio, ma l'unica cosa che farà sugli errori è comprimerli e passarli sul controller. Seguendo il mio esempio sopra, dove la facciata prende un argomento e passa due argomenti al servizio. Supponiamo che il servizio restituisca due valori e che la facciata restituisca un singolo valore al controller. Se c'è qualcosa di sbagliato con uno o entrambi i valori provenienti dal servizio, la facciata può essere progettata per generare un errore one nel controller in cui verrà gestito. (O eventualmente gettato di nuovo in qualche altra parte del codice.)

Non ho familiarità con Java o con il framework Spring, ma sembra che l'intero punto di ResponseEntity sia quello di combinare httpEntity e httpStatus. Non penso che sia compito della facciata spezzarli e fare cose con loro. La facciata deve passare ResponseEntity a un oggetto che si aspetta di ricevere sia httpEntity che httpStatus.