Eu estou com um problema na minha aplicação que ainda não consegui resolver. É um problema de validação. Sempre que um form é preenchido e enviado, a aplicação no servidor faz a validação, usando o Validator do VRaptor (mas isso é um detalhe indiferente para a questão) e, se os dados forem pré-validados, chama-se o DAO.
Teoricamente o DAO não retornaria nenhum tipo de erro se o banco estiver rodando e as consultas já forem testadas: em ambiente de produção espera-se que as ferramentas funcionem estáveis. Tudo bem. Mas alguns problemas podem surgir com a adição de constraints nas lógicas do BD. No meu caso eu tenho uma coluna com o atributo UNIQUE, e não sei como fazer essa validação na minha aplicação.
Estou com 2 soluções, gostaria de pegar a experiência dos colegas e gerar uma discussão sobre essas soluções:
- O DAO trata as exceções dentro dos seus métodos, fazendo o rollback das transações que não puderam ser concluídas, e lançando novas exceções que serão tratadas pela lógica da aplicação (camada de BL, a camada que usa o DAO).
- Usar um DAO mais limpo, de forma que ele trate as exceções internas (fazendo o rollback quando necessário), mas que não gere exceções. Nesse caso entende-se que o programa vá rodar 99,999% das vezes sem problemas, e que se o DAO gerar exceção é porque o banco está fora do ar e a aplicação, por tabela, também está fora do ar. Nesse caso, checa-se as constraints de banco na camada de BL também, utilizando queries (SELET WHERE nome = input, no caso de verificação de unicidade dos registros).
O que vocês fariam? A solução 1 obviamente é a mais elegante, mas o código fica lotado de try/catch e perde legibilidade. No meu caso eu estou fazendo a pré-validação dos dados no BL, faço a chamada ao DAO e verifico por erros novamente. É comum usar DAOs que lançam exceções?