2012-06-25 10 views
5

Sto sviluppando progetti di tipo enterprise usando il pattern DDD. Ho seguito progetti nel mio C# soluzione:Come definire correttamente la strategia di eccezione nell'applicazione enterprise .NET con pattern DDD?

  • modello di dominio - progetto DLL

  • WebUI - ASP.NET progetto MVC3

  • DesktopUI - progetto WPF

  • DAL - Entity Framework Code First

  • Persistenza - Database server SQL

Questo progetto non è grande ma sto cercando di utilizzare tutte le buone pratiche delle applicazioni aziendali.

Quello che mi piacerebbe definire ora è la strategia delle eccezioni, ma non sono sicuro di come affrontarlo. Probabilmente dovrei usare Enterprise Library Exception Handling e Logging Blocks ma non sono sicuro di come inserirlo nell'immagine. Alcuni scenari concreti che sto cercando di risolvere nella mia testa sono i seguenti:

  • Se la nuova entità viene creata dall'utente nell'applicazione WPF, e il pulsante Salva viene cliccato come dovrebbe errore essere riportati e registrati nel caso un'eccezione si verifica a diversi livelli (ad esempio, l'entità non viene creata correttamente in base alle regole di dominio o si è verificato un errore durante il tentativo di persistere nuovo oggetto nel database)

  • L'utente tenta di recuperare l'entità sconosciuta dal database (ad esempio da WebUI specificando ID entità sconosciuta nell'URL)

Capisco che posso definire eccezioni personalizzate ma non sono abbastanza sicuro di dove e come. Dovrebbero essere definiti per ogni strato? So che esiste una pratica di eccezioni, ma ancora non sono sicuro di come utilizzare al meglio tale schema.

Inoltre, dovrei creare un'eccezione personalizzata per ogni errore in alcuni livelli (ad esempio UserAlreadyExistInDatabaseException per provare a salvare due utenti con la stessa email e UnknownUserDatabaseException se provo a ottenere un utente sconosciuto dal DB) o dovrei avere un tipo di eccezione che gestisce più errori di livello (ad esempio DatabaseException e quindi differenzia gli errori con proprietà personalizzate o proprietà Exception.Message).

risposta

6

Vorrei stare lontano dai blocchi di gestione e registrazione delle eccezioni di EntLib perché sono troppo complessi da configurare e gestire in generale. Potete certamente esplorarli per vedere come possono essere affrontati questi tipi di problemi, ma è spesso più facile eseguire la propria soluzione o utilizzare qualcosa come log4net o NLog per la registrazione.

Per quanto riguarda la gestione delle eccezioni, il livello di presentazione (WPF o ASP.NET) deve intercettare e interpretare le eccezioni generate dal livello del servizio dell'applicazione. Il servizio applicativo incapsula il tuo dominio incluso il modello di dominio e il livello di accesso ai dati (repository in DDD speak). Il servizio dell'applicazione può restituire oggetti risultato che possono contenere informazioni di errore o propagare eccezioni dal dominio o DAL.

È necessario creare tipi di eccezioni personalizzate se si intende catturarli per fare qualcosa di specifico con un determinato tipo di eccezione.Un'eccezione come UserAlreadyExistInDatabaseException può essere utile perché il servizio dell'applicazione può catturarla e restituire una sorta di oggetto risultato da interpretare dal livello presentazione, oppure l'eccezione può essere rilevata nel livello di presentazione che a sua volta informa l'utente.

La registrazione può essere eseguita a livello di servizio dell'applicazione o livello di presentazione o entrambi. Ad esempio, un servizio applicativo può rilevare un'eccezione dal DAL, registrarlo e racchiuderlo in un'altra eccezione che il livello di presentazione può interpretare.

utente tenta di recuperare un'entità sconosciuta dal database

Questo può essere gestito in diversi modi. Un modo è che il servizio app restituisce un riferimento null e il livello di presentazione restituisce all'utente un messaggio appropriato. In alternativa, il DAL può generare qualcosa come EntityNotFoundException che può essere catturato nel livello di presentazione, restituendo anche un messaggio appropriato all'utente. Aumentare tale eccezione può essere utile con qualcosa come ASP.NET MVC perché è possibile creare un filtro azione che restituisce una risposta generica dopo aver ricevuto un'eccezione di tale tipo.

+0

Hai dichiarato: "Il servizio dell'applicazione incapsula il tuo dominio incluso il modello di dominio". Pertanto, l'interfaccia utente può accedere al tipo 'UserAlreadyExistInDatabaseException' poiché è incluso in esso. Ma se dividessimo i servizi applicativi in ​​applicationervice-api.jar (interfacce, DTO ecc.) E applicationervice-impl.jar. Solo applicationervice-impl.jar avrebbe accesso a 'UserAlreadyExistInDatabaseException'. Pertanto, un'interfaccia utente che dipende solo da applicationervice-api.jar (disaccoppiamento) non potrebbe agire di conseguenza a questa eccezione ... A cosa pensi? – Mik378

Problemi correlati