Gestione errori nell'architettura a 3 livelli

Question

Come si implementa elegantemente la gestione degli errori? Ad esempio, il mio livello di accesso ai dati può potenzialmente generare 2 tipi di errori: 1) accesso non autorizzato, nel qual caso la pagina dovrebbe nascondere tutto e mostrare solo il messaggio di errore 2) errori che informano l'utente che qualcosa del genere esiste già nel database (ad esempio il nome non è univoco, ad esempio), e in questo caso non vorrei nascondere tutto.

Modificato:

A seguito di alcuni commenti qui ho messo a punto che dovrei creare derivato tipi di eccezione specializzati, come NotAuthorizedException, DuplicateException, etc etc .... è tutto bene e dandy, ma posso vedere 2 problemi potenzialmente:

1) Ogni stored procedure ha un campo di ritorno p_error in cui contiene un messaggio di errore. Dopo aver ottenuto i dati dal DB, ho bisogno di controllare questo campo per vedere quale tipo di errore è stato restituito, quindi posso lanciare un'eccezione appropriata. Quindi, ho ancora bisogno di memorizzare i miei tipi di errore/messaggi di errore da qualche parte ..... In altre parole, come dovrei il messaggio esatto per l'utente (in determinati momenti ho bisogno di) w/o controllare prima il campo p_error. Chi mi riporta all'errore oggetto. Chiunque?

2) Posso trasformarlo potenzialmente in un incubo in cui il numero di eccezioni è uguale al numero di tipi di messaggi di errore.

Mi manca qualcosa qui?

Mille grazie a tutti!

Answer 1

Crea il tuo livello di eccezione.

DALExceptionManager DuplicateException DatabaseException

BLLExceptionManager NotAuthorizedException InvalidDateException

nella presentazione layer, aggiungere questo riferimento e creare un gestore di eccezioni comune. In questo modo sai come gestire i messaggi di eccezione.

Answer 2

È necessario controllare il blocco di gestione delle eccezioni in Enterprise Library. Un sacco di buoni consigli e codeware che circondano le eccezioni del wrapping e passandole tra i livelli.

Answer 3

Dove si trova il livello aziendale e perché non sta controllando Autorizzazione e integrità? Il DAL è troppo basso per essere controllato da quelle regole: se si verifica un problema, è quasi ora di lanciare un'eccezione. Il tuo livello aziendale oi tuoi controller possono rilevare tale eccezione e visualizzare un messaggio ragionevole, ma non è qualcosa che dovresti fare regolarmente.

Answer 4

Un'opzione che stavo pensando di usando è creare una classe di errore, ma poi mi avrebbe bisogno di passare dall'interfaccia utente a livello di business e l'allora ai dati livello di accesso con riferimento

Non sono sicuro di averlo capito. Non devi passare l'oggetto errore in ogni livello. Ad esempio, in uno dei tuoi esempi, errors that inform the user that something like this already exists in the database (say name not unique - for example), un'eccezione sql potrebbe essere generata dal framework e devi solo catturare l'eccezione specifica nel tuo livello aziendale o livello dell'interfaccia utente.

Il blocco di gestione delle eccezioni dalla libreria Enterprise suggerito da altre persone consente di definire una gestione delle eccezioni basata su criteri nel file web.config. Potrebbe essere un buon posto se vuoi sviluppare qualche applicazione aziendale. Ma per un'applicazione semplice, potrebbe non essere necessario andare così lontano.

Answer 5

Ciò che accade nei livelli superiori non dipende dal livello di accesso ai dati. Non dovrebbe nemmeno essere a conoscenza di ciò che i livelli superiori stanno per fare. Se hai un errore chiave duplicato, allora dovrebbe lanciare qualcosa come "DuplicateKeyException". Se dovessi riscontrare un errore di autorizzazione (presumo tu intenda "eccezione"), allora non fare nulla con esso - lascia che bolla di nuovo sul livello dell'interfaccia utente, che può visualizzare una pagina di errore appropriata.

Ricordare che i valori dello stato di errore e queste cose sono la ragione per cui abbiamo inventato le eccezioni.

Answer 6

Il blocco di gestione delle eccezioni delle librerie aziendali è la bomba che molti hanno sottolineato. Usando le politiche puoi fare cose come registrare l'eccezione, avvolgerla in un'eccezione diversa, lanciare una nuova eccezione invece di quella originale. Inoltre, se si desidera eseguire azioni specifiche basate su errori di autenticazione o errori di registrazione duplicati, è sempre possibile creare classi di derivazione derivate specifiche e catturare quei tipi di eccezioni che precludono la necessità di passare qualsiasi oggetto dall'alto verso il basso. Le eccezioni dovrebbero essere sempre in bolla non giù.