2009-09-30 15 views
6

Ho faticato con questo dal primo giorno. Probabilmente non mi aiuta che sono stato circondato da un sacco di codice che non gestisce nemmeno gli errori.Come gestire correttamente gli errori in un'applicazione n-tier?

In ogni caso, sto lavorando con WebForms nel tradizionale design a più livelli: UI-> BLL-> DAL. Di solito quello che faccio (e so che non è giusto) è provare/catturare le mie operazioni sui dati. Se c'è un'eccezione, la butto semplicemente in bolla.

try 
'db operations 
catch ex as exception 
throw 
finally 
'close connections 
end 

Così allora bolle fino alla BLL e c'è un altro try/catch dove andrò a registrare l'errore. Ora voglio avvisare l'utente che qualcosa non va, quindi lo lancio di nuovo, in questo modo bolle all'interfaccia utente. Al livello dell'interfaccia utente, eseguirò un tentativo/cattura e, in caso di errore, visualizzerò un messaggio amichevole.

Quali sono i tuoi pensieri? Cosa posso fare meglio qui?

risposta

5

Come ho capito, hai tre tentativi/catture - una per ogni livello: DAL, BLL, UI.

Si dovrebbe prendere solo quando si sta per fare qualcosa al riguardo.

Da quello che ho capito, è semplicemente passato dal DAL quindi non ce n'è bisogno.

Da BLL si registra l'eccezione e questa è una buona pratica dal momento che sarete in grado di raccogliere dati sulle eccezioni per migliorare eventualmente l'applicazione.

Quindi si cattura sul livello dell'interfaccia utente per tradurre l'eccezione in qualcosa di facile da usare. Va bene.

Quindi mi piacerebbe solo sbarazzarmi del try/catch dal livello DAL - se davvero non si fa nulla di più che annullare l'eccezione.

In alcuni scenari, può essere utile aggiungere un identificatore al BLL che viene passato all'eccezione UI e mostrato agli utenti finali in modo che se chiamano il supporto, il personale di supporto può correlare l'ID dato con un'eccezione su il registro del server.

Ciò può essere fatto, ad esempio, aggiungendo un Guid o qualcos'altro significativo e unico per la raccolta Exception.Data.

+0

Ma se si verifica un errore nel DAL, non è necessario chiudere la connessione per evitare perdite? – Mike

+0

inserisci gli oggetti di connessione/comando in un blocco {} {}} –

+0

Non è necessario ** esplicitamente ** provare/catturare DAL se si utilizza l'istruzione "Utilizzo".Sotto le copertine, "Uso" avvolgerà la tua connessione/comando con un try/finally e li chiuderà infine. –

1

è necessario generare l'eccezione e catture in UI, come ... In BLL

try 
     { 
      //your code 
     } 
     catch (System.Data.SqlClient.SqlException ex) 
     { 
      if (ex.Number == 547) 
      { 
       throw new Exception("ActiveRecord"); 
      } 
     } 
     finally 
     { 
      MasterConnection.Close(); 
     } 

Catech l'execption nell'interfaccia utente e spettacolo utente messaggio amichevole.

if (e.Exception != null) 
    { 
     if (e.Exception.InnerException.Message == "ActiveRecord") 
     { 
      //Show here User freind message 
     } 
    } 
2

A differenza delle altre risposte, ho intenzione di consigliare di rimuovere anche il try/catch dall'interfaccia utente. Il tuo BLL dovrebbe rilevare l'eccezione, registrarlo e quindi fornire un meccanismo per l'interfaccia utente per interrogare quali errori si sono verificati.

Questo risulta in un codice UI più pulito, in quanto non è necessario enumerare tutte le possibili eccezioni che il livello aziendale può generare. È possibile semplificare il codice dell'interfaccia utente a:

if (businessObject.doSomeOperation == true) { 
    // Do whatever you need to here. 
} else { 
    // output error message from businessobject 
    // something like businessObject.LastErrorMessage(); 
} 
Problemi correlati