In quale livello dovrebbero essere gestiti gli errori di servizio?

Question

In quale livello dovrebbero essere gestiti gli errori di servizio?

#1 da (4 voti)
#2 da (1 voti)

0

Sto codificando in un'architettura multitier in Java e eseguo una query su un servizio web.

È possibile gestire meglio gli errori restituiti dal servizio nel livello di accesso ai dati o nel livello aziendale?

Ad esempio, il servizio registra una risposta simile a questa:

<?xml version="1.0" encoding="UTF-8"?>
    <ReturnCode>[integer]</ReturnCode>
    <ReturnMessage>[String correponding to ReturnCode]</ReturnMessage>
    <UpdateTimestamp>[dateTime - only present if ReturnCode == 0]</UpdateTimestamp>
    <UpdateUser>[string - only present if ReturnCode == 0]</UpdateUser>
</xml>

Se ho gestito gli errori nel livello di accesso ai dati, il mio codice Java vorrebbe qualcosa del tipo: Logica degli errori in DAO . (nota che il tipo di dati non ha returnCode o returnMessage campi)

Se gestivo gli errori nel livello aziendale, il codice sarebbe il seguente: Logica errori in BO . (nota che il tipo di dati ha returnCode e returnMessage campi)

design java architecture data-types

posta patstuart 13.08.2014 - 18:06

fonte

2 risposte

1

I livelli sottostanti - service / DAO nel tuo linguaggio - dovrebbero solo generare eccezioni quando li colpiscono. Lascia che il livello dell'interfaccia utente (servizi Web in questo scenario) gestisca come gestirlo per il client.

Il problema principale è che se provi a gestirlo a un livello basso, allora il tuo servizio / dao deve avere conoscenze più intime del top end dello stack, quindi dovrebbero davvero portare a un'intera serie di altri problemi di progettazione. Essere in grado di sparare e dimenticare le eccezioni come questa è ciò che li rende molto più potenti di altre tecniche di gestione degli errori.

risposta data 13.08.2014 - 18:43

fonte

Leggi altre domande sui tag design java architecture data-types

Che cosa significa "banale"? [duplicare] Quando il blocco non è necessario nel multithreading

score 4 · Accepted Answer

Direi che l'approccio Fail-fast è applicabile anche alla tua situazione . Cioè, dovresti gestire l'errore il più vicino possibile alla sua fonte. Se si esegue questa chiamata al servizio Web dal livello aziendale e si desidera salvare i risultati di tale chiamata nel database, è necessario gestire l'errore nel livello aziendale. Se è fatto come parte del livello di accesso ai dati, gestiscilo lì.