Tratamento de erros em 3 arquitetura em camadas

Question

Como faço para implementar o tratamento de erros elegantemente? Por exemplo, a minha camada de acesso a dados podem potencialmente jogar 2 tipos de erros: 1) acesso não autorizado, caso em que a página deve esconder tudo e apenas mostrar a mensagem de erro 2) erros que informam ao usuário que algo como isso já existe no banco de dados (nome digamos não única -. Por exemplo), e neste caso eu não iria querer esconder tudo

EDITADO:

Como resultado aqui alguns comentários eu criei que eu deveria criar tipos de exceção especializados derivados, tais como NotAuthorizedException, DuplicateException, etc etc .... é tudo muito bem e dândi, no entanto eu posso ver 2 problemas potencialmente:

1) Cada proc armazenado tem um p_error campo de declaração, quando ele contém uma mensagem de erro. Ao chegar os dados do DB, eu preciso verificar este campo para ver que tipo de um erro foi devolvido, para que eu possa lançar uma exceções apropriadas. Então, eu ainda preciso para armazenar meus tipos de mensagens de erro / erro em algum lugar ..... Em outras palavras, como é que eu devo a mensagem exata para o usuário (em determinados momentos eu preciso) w / o verificando o campo p_error primeiro. O que me traz de volta ao objeto de erro. Qualquer um?

2) I pode este potencialmente se transformar em um pesadelo onde o número de exceções é igual ao número de tipos de mensagens de erro.

Estou faltando alguma coisa aqui?

Muito obrigado a todos!

Answer 1

Crie a sua própria camada de exceção.

DALExceptionManager DuplicateException DatabaseException

BLLExceptionManager NotAuthorizedException InvalidDateException

Em sua camada de apresentação, adicione referências e criar um manipulador de exceção comum. Desta forma, você sabe como lidar com as mensagens de exceção.

Answer 2

Você deve verificar se a manipulação de exceção bloco na Enterprise Library . Muitas boas dicas e codeware circundante exceções acondicionamento e passá-los entre as camadas.

Answer 3

Onde está a sua camada de negócios, e por isso não está verificando autorização e integridade? A DAL é muito baixo nível para estar verificando essas regras - se você bater um problema lá, é muito muito tempo para lançar uma exceção. Sua camada de negócios ou controladores podem pegar essa exceção, e exibir uma mensagem razoável -. Mas não é algo que você deve ser regularmente fazendo

Answer 4

Uma opção que eu estava pensando em usando é criar uma classe de erro, mas então eu preciso passá-lo a partir da interface do usuário a camada de negócios e, em seguida, os dados camada de acesso por referência

Eu não tenho certeza eu entendo isso. Você não tem que passar o objeto de erro em cada camada. Por exemplo, em um de seu exemplo, errors that inform the user that something like this already exists in the database (say name not unique - for example), uma exceção de SQL pode ser jogado pelo quadro, e você só precisa capturar a exceção específica em sua camada de negócios, ou uma camada de interface do usuário.

Tratamento de exceções bloco pela biblioteca Empresa sugerido por outras pessoas lhe permitirá definir algumas manipulação de exceção baseado em políticas em seu arquivo web.config. Poderia ser bom lugar se você quer desenvolver algum aplicativo corporativo. Mas, para aplicação simples, você pode precisar de não ir tão longe.

Answer 5

O que acontece nas camadas superiores não está à altura de sua camada de acesso a dados. Não deve mesmo estar ciente de que as camadas superiores vão fazer. Se você tem um erro de chave duplicada, então ele deve jogar algo como um "DuplicateKeyException". Se você deve bater um erro de autorização (presumo que você quer dizer "exceção"), então não fazer nada com ele - deixá-lo borbulhar de volta até a camada de interface do usuário, que pode exibir uma página de erro apropriada

.

Lembre-se que os valores de estado de erro e essas coisas são a razão de nós inventamos exceções.

Answer 6

Empresa biblioteca de manipulação de exceção do bloco é a bomba como muitos têm apontado. Usando políticas que você pode fazer coisas como registrando a exceção, envolvê-lo em uma exceção diferente, lançando uma nova exceção em vez do original. Além disso, se você estiver olhando para executar ações específicas com base em erros de autenticação ou erros de registro duplicado, etc, você sempre pode criar classes de exceção específicos derivados e pegar esses tipos de exceção que evita a necessidade de passar todos os objetos de cima para baixo. Exceções devem sempre borbulhar não para baixo.