em minhas aplicações, eu controlo a inclusão, alteração etc. no banco de dados. Por exemplo, se for incluir um registro eu verifico, usando o java, se não viola alguma regra.
Recentemente, eu deixei esse trabalho para o banco de dados capturando, por exemplo, MySQLIntegrityConstraintViolationException na camada de controle e repassando como causa dentro de uma exceção minha.
Essa abordagem está correta? O código ficou muito mais claro mas com isto eu transferi para o banco de dados um pouco da responsabilidade pela aplicação.
eu discordo, se você nao usar coisas especificas do sgdb ele fica portavel ainda, agora usar DAO ajuda as pessoas a nao usar recursos do SGDB mas as vezes os fazem ficar cego e acreditar que só existe aquela solução, aqui onde trabalho temos um sistema que foi feito sobre access e foi migrado para postgresql, pouca coisa teve que ser modificada, como por exemplo o Driver e informações da conexão, o resto ficou igual e sem prejuízo algum, mas sempre houve uma preocupação em se manter um código portável, até porque foi um projeto que cresceu sem ninguém acreditar.
dica, sempre use padrões pq eles na maioria das vezes dão certo mas lembre-se que existem outras formas de resolver o mesmo problema.
Gosto dessa abordagem, mas como já dito, se você usar queries e exceções de um banco específico, a portabilidade vai por água abaixo…
Já pensou em usar o Hibernate? Ele já trás várias exceções como essa prontas e o melhor, ele se vira para ser compatível com os bancos.
…mas ai fico me perguntando será que o acesso a essas informações nao ficarão mais lenta no banco de dados??? agora sobre o codigo esta legivel ou não, concordo que o uso de patterns é a melhor saida, além do que foram inventados para isso, certo???e também concordo que também temos que usar da melhor forma possivel as ferramentas e nao sobrecarregar ninguem…assim a aplicação não sofre…digo isso pq onde trabalhei sempre escutava os DBAs reclarem de tudo que fosse feito no banco de dados…