Loading ...
Sorry, an error occurred while loading the content.
 

Re: [riojug] Deixando um pouco de trabalho para o banco de dados

Expand Messages
  • Guilherme Chapiewski
    O que você fez foi criar um alto acoplamento entre a sua aplicação e o banco de dados. Sua aplicação agora nunca mais vai poder trocar de banco de dados
    Message 1 of 14 , Feb 9, 2008
      O que você fez foi criar um alto acoplamento entre a sua aplicação e o banco de dados. Sua aplicação agora nunca mais vai poder trocar de banco de dados sem um refactoring gigantesco!

      É uma boa prática não acoplar sua aplicação a nenhuma implementação de banco de dados específica.

      Aí alguém pode falar: mas eu nunca ví uma aplicação trocar de banco de dados. E é verdade. Eu só ví uma vez. Mas a questão é que o esforço para desenvolver com e sem esse acoplamento é praticamente o mesmo, então acredito que valha a pena fazer da forma correta.

      [ ]s, gc

      --
      Guilherme Chapiewski
      http://gc.blog.br


      Em 08/02/08, Renato Pinheiro de Souza <renato.pinheiro@...> escreveu:

      Oi Pessoal,

      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 que criei.

      Essa abordagem está correta? O código ficou muito mais limpo mas com isto eu transferi para o banco de dados um pouco da responsabilidade pela aplicação.

      Atenciosamente,
      Renato Pinheiro
      www.gpi.ufrj.br




    • Renato Pinheiro de Souza
      Concordo Guilherme. Desta maneira acoplei a aplicação ao banco mas, com relação ao esforço de desenvolvimento, como disse na mensagem anterior, me pareceu
      Message 2 of 14 , Feb 10, 2008
            Concordo Guilherme. Desta maneira acoplei a aplicação ao banco mas, com relação ao esforço de desenvolvimento, como disse na mensagem anterior, me pareceu muito mais simples usar os recursos do banco do que tratar "in code" as integridade dos relacionamentos. (ok, pode ser que eu não estivesse tratando "in code" da maneira mais correta e simples).

            Em tempo, mesmo em uma troca de banco, a maiorias dos BDs que já tive acesso possuem pelo menos um conjunto de recursos similares, dentre eles está o controle de integridade dos relacionamentos. Neste caso, as exceções levantadas no JDBC não seriam as mesmas? Não precisando portanto reescrever nada.

        []s,
        Renato

        Guilherme Chapiewski escreveu:

        O que você fez foi criar um alto acoplamento entre a sua aplicação e o banco de dados. Sua aplicação agora nunca mais vai poder trocar de banco de dados sem um refactoring gigantesco!

        É uma boa prática não acoplar sua aplicação a nenhuma implementação de banco de dados específica.

        Aí alguém pode falar: mas eu nunca ví uma aplicação trocar de banco de dados. E é verdade. Eu só ví uma vez. Mas a questão é que o esforço para desenvolver com e sem esse acoplamento é praticamente o mesmo, então acredito que valha a pena fazer da forma correta.

        [ ]s, gc

        --
        Guilherme Chapiewski
        http://gc.blog. br


        Em 08/02/08, Renato Pinheiro de Souza <renato.pinheiro@ pobox.com> escreveu:

        Oi Pessoal,

        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, MySQLIntegrityConst raintViolationEx ception na camada de controle e repassando como causa dentro de uma exceção que criei.

        Essa abordagem está correta? O código ficou muito mais limpo mas com isto eu transferi para o banco de dados um pouco da responsabilidade pela aplicação.

        Atenciosamente,
        Renato Pinheiro
        www.gpi.ufrj. br




      • Bruno Luiz Pereira da Silva
        Renato, o que você fez realmente te poupa um bom trabalho, e especialmente um trabalho bem chato se vc está usando jdbc diretamente para fazer o acesso ao
        Message 3 of 14 , Feb 10, 2008
          Renato, o que você fez realmente te poupa um bom trabalho, e especialmente um trabalho bem chato se vc está usando jdbc diretamente para fazer o acesso ao banco de dados.
          Entretanto, o que o Guilherme falou é verdade, esse acoplamento fica muito forte e te impede de reaproveitar a abordagem em outro banco de dados.
          Uma solução que te permite deixar o controle de restrições de integridade para o banco sem te acoplar a um banco de dados específico é utilizar o controle de restrições de integridade da API jdbc.

          Na versão 4 da API jdbc (disponível a partir do Java 6) temos uma exceção chamada SQLIntegrityConstraintViolationException. Se você puder usar Java 6 na sua aplicação e tiver um driver jdbc suportando jdbc 4.0, você consegue ter o controle de restrições de integridade feito pelo banco de dados sem te acoplar a um banco específico.

          Eu estou te falando isso apenas pelo conhecimento do recurso e da API, mas nunca cheguei a usar este recurso ainda. Acredito que os drivers da maioria dos bancos de dados mais comuns suporte isso bem, então é muito válido vc tentar trocar essa sua abordagem da exception específica do MySQL pela exception da API jdbc.

          Se você conseguir testar isso, responda novamente aqui para que possamos saber sobre o funcionamento deste novo controle da API. O jdbc 4.0 trouxe algumas exceptions mais específicas do que SQLException, mas todas herdam de SQLException. É sempre bom conhecermos estes novos recursos para nos livrar de coisas como controle de restrições de integridade em código Java, o que é muito chato.

          Espero ter ajudado.

          --
          Atenciosamente,

          Bruno Luiz Pereira da Silva
          blpsilva@...
          http://brunopereira.com.br

          2008/2/10 Guilherme Chapiewski <guilherme.chapiewski@...>:

          O que você fez foi criar um alto acoplamento entre a sua aplicação e o banco de dados. Sua aplicação agora nunca mais vai poder trocar de banco de dados sem um refactoring gigantesco!

          É uma boa prática não acoplar sua aplicação a nenhuma implementação de banco de dados específica.

          Aí alguém pode falar: mas eu nunca ví uma aplicação trocar de banco de dados. E é verdade. Eu só ví uma vez. Mas a questão é que o esforço para desenvolver com e sem esse acoplamento é praticamente o mesmo, então acredito que valha a pena fazer da forma correta.

          [ ]s, gc

          --
          Guilherme Chapiewski
          http://gc.blog.br


          Em 08/02/08, Renato Pinheiro de Souza <renato.pinheiro@...> escreveu:

          Oi Pessoal,

          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 que criei.

          Essa abordagem está correta? O código ficou muito mais limpo mas com isto eu transferi para o banco de dados um pouco da responsabilidade pela aplicação.

          Atenciosamente,
          Renato Pinheiro
          www.gpi.ufrj.br




          -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
          Rio Java Users Group: http://www.riojug.org
          Moderadores: riojug-owner@yahoogroups.com
          -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
          Outras listas do RioJUG:
          SCJP (groups.yahoo.com/group/scjp_riojug)
          SCWCD (groups.yahoo.com/group/scwcd_riojug)
          -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
          Yahoo! Finance

          It's Now Personal

          Guides, news,

          advice & more.

          New web site?

          Drive traffic now.

          Get your business

          on Yahoo! search.

          Yahoo! Groups

          w/ John McEnroe

          Join the All-Bran

          Day 10 Club.

          .
          _._,___




        • Victor Hogemann
          Bom, Só pra complementar o que todo mundo já falou... Além de você ter um acoplamento muito forte entre a aplicação e o BD, você agora tem um único
          Message 4 of 14 , Feb 10, 2008
            Bom,

            Só pra complementar o que todo mundo já falou... Além de você ter um acoplamento muito forte entre a aplicação e o BD, você agora tem um único ponto de falha para testar a integridade dos dados. Pior, você está confiando no MySQL, que historicamente sempre trocou integridade por performance.

            Outra, imagino que seu banco de dados seja pequeno e tenha um tráfego de dados baixo... aí o impacto de ter integridade referencial checada no banco é baixo, mas na minha experiência quase sempre conforme a demanda ao banco cresce a tendência é remover as constraints para ganhar mais performance. E eu não estou falando de MySQL não, estou falando de Oracle, e de um dos maiores sites de comércio eletrônico do país... sim, na maioria dos bancos não tem checagem de integridade referêncial por causa de performance.

            Aí a responsabilidade pela integridade dos dados cai inteiramente sobre a aplicação. E é justamente por causa disso que grandes Application Servers tem suporte a transações globais, por quê além de você não poder se garantir só na checagem do banco, muitas vezes você está falando com dois, três ou mais recursos diferentes na mesma operação... e se alguma coisa sair errado você vai ter que fazer rollback em todos esses recursos.

            Resumindo, o que você fez não está errado, e foi uma sacada legal... Só não é a melhor solução em todos os casos.

            []s

            2008/2/8 Renato Pinheiro de Souza <renato.pinheiro@...>:

            Oi Pessoal,

            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 que criei.

            Essa abordagem está correta? O código ficou muito mais limpo mas com isto eu transferi para o banco de dados um pouco da responsabilidade pela aplicação.

            Atenciosamente,
            Renato Pinheiro
            www.gpi.ufrj.br



            --
            Victor Guilherme Hogemann
            http://victor.hogemann.eti.br
          • Renato Pinheiro de Souza
            Oi Bruno, foi exatamente essa exceção que utilizei, o código ficou assim: try{ lutadorDAO.update( new Lutador( id, nome, equipeDAO.buscaEquipe(idEquipe),
            Message 5 of 14 , Feb 10, 2008
              Oi Bruno,

              foi exatamente essa exceção que utilizei, o código ficou assim:

                      try{
                          lutadorDAO.update(
                                  new Lutador( id, nome, equipeDAO.buscaEquipe(idEquipe),
                                  graduacao, gub, peso, idade, documento, email, sexo));
                      } catch (MySQLIntegrityConstraintViolationException ex) {
                          throw new LutadorDadoIncorreto("Já existe um lutador com " +
                                  "este documento no banco de dados");
                      }

              Pelo que li, poderia inclusive passar a MySQLIntegrityConstraintViolationException como causa (está correto?) mas, pelo menos a princípio, não achei necessário.

              Testei o funcionamento, quando tento qualquer operação que viole as regras de integridade do banco, esta exceção é lançada.

              Valeu a ajuda Bruno.

              []s,
              Renato


              Bruno Luiz Pereira da Silva escreveu:

              Renato, o que você fez realmente te poupa um bom trabalho, e especialmente um trabalho bem chato se vc está usando jdbc diretamente para fazer o acesso ao banco de dados.
              Entretanto, o que o Guilherme falou é verdade, esse acoplamento fica muito forte e te impede de reaproveitar a abordagem em outro banco de dados.
              Uma solução que te permite deixar o controle de restrições de integridade para o banco sem te acoplar a um banco de dados específico é utilizar o controle de restrições de integridade da API jdbc.

              Na versão 4 da API jdbc (disponível a partir do Java 6) temos uma exceção chamada SQLIntegrityConstra intViolationExce ption. Se você puder usar Java 6 na sua aplicação e tiver um driver jdbc suportando jdbc 4.0, você consegue ter o controle de restrições de integridade feito pelo banco de dados sem te acoplar a um banco específico.

              Eu estou te falando isso apenas pelo conhecimento do recurso e da API, mas nunca cheguei a usar este recurso ainda. Acredito que os drivers da maioria dos bancos de dados mais comuns suporte isso bem, então é muito válido vc tentar trocar essa sua abordagem da exception específica do MySQL pela exception da API jdbc.

              Se você conseguir testar isso, responda novamente aqui para que possamos saber sobre o funcionamento deste novo controle da API. O jdbc 4.0 trouxe algumas exceptions mais específicas do que SQLException, mas todas herdam de SQLException. É sempre bom conhecermos estes novos recursos para nos livrar de coisas como controle de restrições de integridade em código Java, o que é muito chato.

              Espero ter ajudado.

              --
              Atenciosamente,

              Bruno Luiz Pereira da Silva
              blpsilva@gmail. com
              http://brunopereira .com.br

              2008/2/10 Guilherme Chapiewski <guilherme.chapiewsk i@...>:

              O que você fez foi criar um alto acoplamento entre a sua aplicação e o banco de dados. Sua aplicação agora nunca mais vai poder trocar de banco de dados sem um refactoring gigantesco!

              É uma boa prática não acoplar sua aplicação a nenhuma implementação de banco de dados específica.

              Aí alguém pode falar: mas eu nunca ví uma aplicação trocar de banco de dados. E é verdade. Eu só ví uma vez. Mas a questão é que o esforço para desenvolver com e sem esse acoplamento é praticamente o mesmo, então acredito que valha a pena fazer da forma correta.

              [ ]s, gc

              --
              Guilherme Chapiewski
              http://gc.blog. br


              Em 08/02/08, Renato Pinheiro de Souza <renato.pinheiro@ pobox.com> escreveu:

              Oi Pessoal,

              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, MySQLIntegrityConst raintViolationEx ception na camada de controle e repassando como causa dentro de uma exceção que criei.

              Essa abordagem está correta? O código ficou muito mais limpo mas com isto eu transferi para o banco de dados um pouco da responsabilidade pela aplicação.

              Atenciosamente,
              Renato Pinheiro
              www.gpi.ufrj. br



              -=-=-=-=-=-= -=-=-=-=- =-=-=-=-= -=-=-=-=- =-=-
              Rio Java Users Group: http://www.riojug. org
              Moderadores: riojug-owner@ yahoogroups. com
              -=-=-=-=-=-= -=-=-=-=- =-=-=-=-= -=-=-=-=- =-=-
              Outras listas do RioJUG:
              SCJP (groups.yahoo. com/group/ scjp_riojug)
              SCWCD (groups.yahoo. com/group/ scwcd_riojug)
              -=-=-=-=-=-= -=-=-=-=- =-=-=-=-= -=-=-=-=- =-=-
              Yahoo! Finance

              It's Now Personal

              Guides, news,

              advice & more.

              New web site?

              Drive traffic now.

              Get your business

              on Yahoo! search.

              Yahoo! Groups

              w/ John McEnroe

              Join the All-Bran

              Day 10 Club.

              .
              _._,___





            • Renato Pinheiro de Souza
              Oi Victor, ótimo ponto. Realmente não tenho experiência com os bancos, é um pena que sacrifiquem integridade por performace (devia ser o contrário
              Message 6 of 14 , Feb 10, 2008
                Oi Victor,

                ótimo ponto. Realmente não tenho experiência com os bancos, é um pena que sacrifiquem integridade por performace (devia ser o contrário SEMPRE).

                Realmente minha aplicação é pequena e com pouca ativade de banco na verdade (estou desenvolvendo um controle de placar para lutas de taekwondo. Quem assistiu alguma luta no pan americano deve ter visto os arbitros marcandos os pontos através de joysticks nos cantos dos tatames).

                Em outra aplicação pequena que fiz (um controle de freqüência por impressão digital), trouxe para o código toda a validação e, em algumas operações, gastei MUITAS linhas de código para garantir a integridade.

                A questão talvez seja mesmo avaliar onde usar ou não o banco para manter a integridade.

                Valeu a força de todos.

                []s,
                Renato

                Victor Hogemann escreveu:

                Bom,

                Só pra complementar o que todo mundo já falou... Além de você ter um acoplamento muito forte entre a aplicação e o BD, você agora tem um único ponto de falha para testar a integridade dos dados. Pior, você está confiando no MySQL, que historicamente sempre trocou integridade por performance.

                Outra, imagino que seu banco de dados seja pequeno e tenha um tráfego de dados baixo... aí o impacto de ter integridade referencial checada no banco é baixo, mas na minha experiência quase sempre conforme a demanda ao banco cresce a tendência é remover as constraints para ganhar mais performance. E eu não estou falando de MySQL não, estou falando de Oracle, e de um dos maiores sites de comércio eletrônico do país... sim, na maioria dos bancos não tem checagem de integridade referêncial por causa de performance.

                Aí a responsabilidade pela integridade dos dados cai inteiramente sobre a aplicação. E é justamente por causa disso que grandes Application Servers tem suporte a transações globais, por quê além de você não poder se garantir só na checagem do banco, muitas vezes você está falando com dois, três ou mais recursos diferentes na mesma operação... e se alguma coisa sair errado você vai ter que fazer rollback em todos esses recursos.

                Resumindo, o que você fez não está errado, e foi uma sacada legal... Só não é a melhor solução em todos os casos.

                []s

                2008/2/8 Renato Pinheiro de Souza <renato.pinheiro@ pobox.com>:

                Oi Pessoal,

                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, MySQLIntegrityConst raintViolationEx ception na camada de controle e repassando como causa dentro de uma exceção que criei.

                Essa abordagem está correta? O código ficou muito mais limpo mas com isto eu transferi para o banco de dados um pouco da responsabilidade pela aplicação.

                Atenciosamente,
                Renato Pinheiro
                www.gpi.ufrj. br



                --
                Victor Guilherme Hogemann
                http://victor. hogemann. eti.br

              • wardog1
                O q tu podes fazer q e + simples e barato e desacoplar a logica do negocio da logica d dados: 1) Utiliza factories para criar 1 instancia do objeto q manipula
                Message 7 of 14 , Feb 11, 2008
                  O q tu podes fazer q e + simples e barato e desacoplar a logica do
                  negocio da logica d dados:

                  1) Utiliza factories para criar 1 instancia do objeto q manipula a tua base.
                  2) Cria interfaces e classes abstratas com metodos adequados a tua
                  manipulacao d dados
                  3) Cria classes implementado as interfaces e classes abstratas e
                  coloca o codigo sql necessario e dependente d banco nestas classes.
                  4) C tiver troca d banco, basta criar o item 3 para a nova base e a
                  aplicacao fica intacta

                  C precisar d 1 exemplo e so pedir.

                  p.s
                  nem pensa em usar hibernate e similares: a curva d aprendizagem e
                  baixissima e e praticamente inutil pra queries agregadas.

                  On 2/10/08, Guilherme Chapiewski <guilherme.chapiewski@...> wrote:
                  >
                  >
                  >
                  >
                  >
                  >
                  > O que você fez foi criar um alto acoplamento entre a sua aplicação e o banco de dados. Sua aplicação agora nunca mais vai poder trocar de banco de dados sem um refactoring gigantesco!
                  >
                  > É uma boa prática não acoplar sua aplicação a nenhuma implementação de banco de dados específica.
                  >
                  > Aí alguém pode falar: mas eu nunca ví uma aplicação trocar de banco de dados. E é verdade. Eu só ví uma vez. Mas a questão é que o esforço para desenvolver com e sem esse acoplamento é praticamente o mesmo, então acredito que valha a pena fazer da forma correta.
                  >
                  > [ ]s, gc
                  >
                  > --
                  > Guilherme Chapiewski
                  > http://gc.blog.br
                  >
                  >
                  >
                  > Em 08/02/08, Renato Pinheiro de Souza <renato.pinheiro@...> escreveu:
                • Marcos Dantas
                  Recursos similares???? HAHAHAHAHAHAHAHA Vou te passar uma stored-procedure de Oracle para você converter para SQL-Server.... ou ao contrário. Nunca fiquei
                  Message 8 of 14 , Feb 15, 2008
                    Recursos similares????
                    HAHAHAHAHAHAHAHA

                    Vou te passar uma stored-procedure de Oracle para você converter para SQL-Server.... ou ao contrário.
                    Nunca fiquei tão feliz quanto no dia que parei de trabalhar com um sistema fortemente acoplado po um interamente desacoplado.

                    Abraços

                    Marcos Dantas



                    >  Em tempo, mesmo em uma troca de banco, a maiorias dos BDs que já
                    tive acesso possuem pelo menos um conjunto de >recursos similares, dentre eles está o controle de integridade dos relacionamentos. Neste caso, as exceções levantadas no JDBC >não seriam as mesmas? Não precisando portanto reescrever nada.

                    Em 10/02/08, Renato Pinheiro de Souza <renato.pinheiro@...> escreveu:

                        Concordo Guilherme. Desta maneira acoplei a aplicação ao banco mas, com relação ao esforço de desenvolvimento, como disse na mensagem anterior, me pareceu muito mais simples usar os recursos do banco do que tratar "in code" as integridade dos relacionamentos. (ok, pode ser que eu não estivesse tratando "in code" da maneira mais correta e simples).

                        Em tempo, mesmo em uma troca de banco, a maiorias dos BDs que já tive acesso possuem pelo menos um conjunto de recursos similares, dentre eles está o controle de integridade dos relacionamentos. Neste caso, as exceções levantadas no JDBC não seriam as mesmas? Não precisando portanto reescrever nada.

                    []s,
                    Renato

                    Guilherme Chapiewski escreveu:

                    O que você fez foi criar um alto acoplamento entre a sua aplicação e o banco de dados. Sua aplicação agora nunca mais vai poder trocar de banco de dados sem um refactoring gigantesco!

                    É uma boa prática não acoplar sua aplicação a nenhuma implementação de banco de dados específica.

                    Aí alguém pode falar: mas eu nunca ví uma aplicação trocar de banco de dados. E é verdade. Eu só ví uma vez. Mas a questão é que o esforço para desenvolver com e sem esse acoplamento é praticamente o mesmo, então acredito que valha a pena fazer da forma correta.

                    [ ]s, gc

                    --
                    Guilherme Chapiewski
                    http://gc.blog.br


                    Em 08/02/08, Renato Pinheiro de Souza <renato.pinheiro@...> escreveu:

                    Oi Pessoal,

                    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 que criei.

                    Essa abordagem está correta? O código ficou muito mais limpo mas com isto eu transferi para o banco de dados um pouco da responsabilidade pela aplicação.

                    Atenciosamente,
                    Renato Pinheiro
                    www.gpi.ufrj.br





                  • fabiolnmiranda
                    Concordo que uma ferramenta de mapeamento não se aprende a usar da noite pro dia. Sendo realista, nos primeiros 3 a 6 meses tudo é aprendizado, tentativa e
                    Message 9 of 14 , Feb 15, 2008
                      Concordo que uma ferramenta de mapeamento não se aprende a usar da
                      noite pro dia. Sendo realista, nos primeiros 3 a 6 meses tudo é
                      aprendizado, tentativa e erro, a partir daí aos poucos se começa a
                      ficar produtivo.

                      Porém garanto que vale sim o esforço (produtividade, portabilidade,
                      mantenibilidade, diminui necessidade de lidar direto com o banco -
                      muitas vezes eliminando-a, etc). No caso do Hibernate, há inclusive
                      o hbm2ddl, que gera o BD a partir de seu modelo OO (seja por
                      metadados xml ou anotações). Era meio desconfiado de toda essa
                      bonança, mas tenho usado há uns 2 meses, e simplesmente funciona!

                      Além disso, os ORM atuais possuem recursos que minimizam
                      drasticamente a necessidade de escrever queries "na unha", através
                      da EntityManager API, do mapeamento de heranças e de
                      relacionamentos. Na prática, as aplicações que já desenvolvi
                      necessitaram de queries apenas em lógicas mais complexas, e no
                      momento de consolidar relatórios.

                      Sobre a questão das queries, volto a discordar. A princípio os ORM
                      suportam funções agregadas, queries encadeadas, etc... Até onde
                      precisei o Hibernate me atendeu bem. Passei por alguns poucos casos
                      de queries mais monstruosas, onde o Hibernate reclamou, forçando-me
                      a rever a query e encontrar uma melhor, que ele rodasse.

                      Se a HQL não der conta, pode-se usar queries nativas (é bom saber
                      que isso existe, mas sinceramente ainda não precisei usá-lo).

                      Recomendo a leitura cuidadosa do capítulo 14 do Hibernate. Tem
                      vários exemplos, sempre acabo aprendendo alguma coisa toda vez que
                      faço uma consulta a essa referência.

                      Logicamente, sempre poderão haver casos onde será vantajoso lidar
                      direto com o banco, nada que um DAO não possa encapsular e esconder
                      da aplicação.

                      Abs
                      Fábio.

                      --- In riojug@yahoogroups.com, wardog1 <wardog1@...> wrote:
                      >
                      > O q tu podes fazer q e + simples e barato e desacoplar a logica do
                      > negocio da logica d dados:
                      >
                      > 1) Utiliza factories para criar 1 instancia do objeto q manipula a
                      tua base.
                      > 2) Cria interfaces e classes abstratas com metodos adequados a tua
                      > manipulacao d dados
                      > 3) Cria classes implementado as interfaces e classes abstratas e
                      > coloca o codigo sql necessario e dependente d banco nestas classes.
                      > 4) C tiver troca d banco, basta criar o item 3 para a nova base e a
                      > aplicacao fica intacta
                      >
                      > C precisar d 1 exemplo e so pedir.
                      >
                      > p.s
                      > nem pensa em usar hibernate e similares: a curva d aprendizagem e
                      > baixissima e e praticamente inutil pra queries agregadas.
                      >
                      > On 2/10/08, Guilherme Chapiewski <guilherme.chapiewski@...> wrote:
                      > >
                      > >
                      > >
                      > >
                      > >
                      > >
                      > > O que você fez foi criar um alto acoplamento entre a sua
                      aplicação e o banco de dados. Sua aplicação agora nunca mais vai
                      poder trocar de banco de dados sem um refactoring gigantesco!
                      > >
                      > > É uma boa prática não acoplar sua aplicação a nenhuma
                      implementação de banco de dados específica.
                      > >
                      > > Aí alguém pode falar: mas eu nunca ví uma aplicação trocar de
                      banco de dados. E é verdade. Eu só ví uma vez. Mas a questão é que o
                      esforço para desenvolver com e sem esse acoplamento é praticamente o
                      mesmo, então acredito que valha a pena fazer da forma correta.
                      > >
                      > > [ ]s, gc
                      > >
                      > > --
                      > > Guilherme Chapiewski
                      > > http://gc.blog.br
                      > >
                      > >
                      > >
                      > > Em 08/02/08, Renato Pinheiro de Souza <renato.pinheiro@...>
                      escreveu:
                      >
                    • Bruno Luiz Pereira da Silva
                      Opa, o que eu tinha sugerido é que você troque o catch(MySQLIntegrityConstraintViolationException) por: catch (SQLIntegrityConstraintViolationException).
                      Message 10 of 14 , Feb 27, 2008
                        Opa, o que eu tinha sugerido é que você troque o catch(MySQLIntegrityConstraintViolationException) por:
                        catch (SQLIntegrityConstraintViolationException).

                        Esta exception foi introduzida no Java 6, com a versão 4 do jdbc. Caso você tenha liberdade de usar Java 6 e um driver jdbc que suporte jdbc 4, você pode utilizar este catch. Ele te daria o mesmo recurso que vc tem ao usar a Exception específica do MySQL, mas sem te amarrar ao MySQL.

                        Você já tentou usar essa SQLIntegrityConstraintViolationException? Pela sua mensagem eu não entendi bem se você tinha tentado usar essa do Java 6 ou apenas a específica do MySQL. Se já usou a do Java 6, depois comenta os resultados então.

                         --
                        Atenciosamente,

                        Bruno Luiz Pereira da Silva
                        blpsilva@...
                        http://brunopereira.com.br

                        2008/2/10 Renato Pinheiro de Souza <renato.pinheiro@...>:

                        Oi Bruno,

                        foi exatamente essa exceção que utilizei, o código ficou assim:

                                try{
                                    lutadorDAO.update(
                                            new Lutador( id, nome, equipeDAO.buscaEquipe(idEquipe),
                                            graduacao, gub, peso, idade, documento, email, sexo));
                                } catch (MySQLIntegrityConstraintViolationException ex) {
                                    throw new LutadorDadoIncorreto("Já existe um lutador com " +
                                            "este documento no banco de dados");
                                }

                        Pelo que li, poderia inclusive passar a MySQLIntegrityConstraintViolationException como causa (está correto?) mas, pelo menos a princípio, não achei necessário.

                        Testei o funcionamento, quando tento qualquer operação que viole as regras de integridade do banco, esta exceção é lançada.

                        Valeu a ajuda Bruno.

                        []s,
                        Renato


                        Bruno Luiz Pereira da Silva escreveu:

                        Renato, o que você fez realmente te poupa um bom trabalho, e especialmente um trabalho bem chato se vc está usando jdbc diretamente para fazer o acesso ao banco de dados.
                        Entretanto, o que o Guilherme falou é verdade, esse acoplamento fica muito forte e te impede de reaproveitar a abordagem em outro banco de dados.
                        Uma solução que te permite deixar o controle de restrições de integridade para o banco sem te acoplar a um banco de dados específico é utilizar o controle de restrições de integridade da API jdbc.

                        Na versão 4 da API jdbc (disponível a partir do Java 6) temos uma exceção chamada SQLIntegrityConstraintViolationException. Se você puder usar Java 6 na sua aplicação e tiver um driver jdbc suportando jdbc 4.0, você consegue ter o controle de restrições de integridade feito pelo banco de dados sem te acoplar a um banco específico.

                        Eu estou te falando isso apenas pelo conhecimento do recurso e da API, mas nunca cheguei a usar este recurso ainda. Acredito que os drivers da maioria dos bancos de dados mais comuns suporte isso bem, então é muito válido vc tentar trocar essa sua abordagem da exception específica do MySQL pela exception da API jdbc.

                        Se você conseguir testar isso, responda novamente aqui para que possamos saber sobre o funcionamento deste novo controle da API. O jdbc 4.0 trouxe algumas exceptions mais específicas do que SQLException, mas todas herdam de SQLException. É sempre bom conhecermos estes novos recursos para nos livrar de coisas como controle de restrições de integridade em código Java, o que é muito chato.

                        Espero ter ajudado.

                        --
                        Atenciosamente,

                        Bruno Luiz Pereira da Silva
                        blpsilva@...
                        http://brunopereira.com.br

                        2008/2/10 Guilherme Chapiewski <guilherme.chapiewski@...>:

                        O que você fez foi criar um alto acoplamento entre a sua aplicação e o banco de dados. Sua aplicação agora nunca mais vai poder trocar de banco de dados sem um refactoring gigantesco!

                        É uma boa prática não acoplar sua aplicação a nenhuma implementação de banco de dados específica.

                        Aí alguém pode falar: mas eu nunca ví uma aplicação trocar de banco de dados. E é verdade. Eu só ví uma vez. Mas a questão é que o esforço para desenvolver com e sem esse acoplamento é praticamente o mesmo, então acredito que valha a pena fazer da forma correta.

                        [ ]s, gc

                        --
                        Guilherme Chapiewski
                        http://gc.blog.br


                        Em 08/02/08, Renato Pinheiro de Souza <renato.pinheiro@...> escreveu:

                        Oi Pessoal,

                        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 que criei.

                        Essa abordagem está correta? O código ficou muito mais limpo mas com isto eu transferi para o banco de dados um pouco da responsabilidade pela aplicação.

                        Atenciosamente,
                        Renato Pinheiro
                        www.gpi.ufrj.br



                        -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
                        Rio Java Users Group: http://www.riojug.org
                        Moderadores: riojug-owner@yahoogroups.com
                        -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
                        Outras listas do RioJUG:
                        SCJP (groups.yahoo.com/group/scjp_riojug)
                        SCWCD (groups.yahoo.com/group/scwcd_riojug)
                        -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
                        Yahoo! Finance

                        It's Now Personal

                        Guides, news,

                        advice & more.

                        New web site?

                        Drive traffic now.

                        Get your business

                        on Yahoo! search.

                        Yahoo! Groups

                        w/ John McEnroe

                        Join the All-Bran

                        Day 10 Club.

                        .
                        _._,___






                      • Renato Pinheiro de Souza
                        Não prestei atenção, vou testar com a SQLIntegrityConstraintViolationException e dou notícias. Em tempo, enviei a mensagem a muito tempo, não sei porque
                        Message 11 of 14 , Feb 27, 2008
                          Não prestei atenção, vou testar com a SQLIntegrityConstraintViolationException e dou notícias.

                          Em tempo, enviei a mensagem a muito tempo, não sei porque só chegou agora.

                          Att.,
                          Renato

                          Bruno Luiz Pereira da Silva escreveu:

                          Opa, o que eu tinha sugerido é que você troque o catch(MySQLIntegrit yConstraintViola tionException) por:
                          catch (SQLIntegrityConstr aintViolationExc eption).

                          Esta exception foi introduzida no Java 6, com a versão 4 do jdbc. Caso você tenha liberdade de usar Java 6 e um driver jdbc que suporte jdbc 4, você pode utilizar este catch. Ele te daria o mesmo recurso que vc tem ao usar a Exception específica do MySQL, mas sem te amarrar ao MySQL.

                          Você já tentou usar essa SQLIntegrityConstra intViolationExce ption? Pela sua mensagem eu não entendi bem se você tinha tentado usar essa do Java 6 ou apenas a específica do MySQL. Se já usou a do Java 6, depois comenta os resultados então.

                           --
                          Atenciosamente,

                          Bruno Luiz Pereira da Silva
                          blpsilva@gmail. com
                          http://brunopereira .com.br

                          2008/2/10 Renato Pinheiro de Souza <renato.pinheiro@ pobox.com>:

                          Oi Bruno,

                          foi exatamente essa exceção que utilizei, o código ficou assim:

                                  try{
                                      lutadorDAO.update(
                                              new Lutador( id, nome, equipeDAO.buscaEqui pe(idEquipe) ,
                                              graduacao, gub, peso, idade, documento, email, sexo));
                                  } catch (MySQLIntegrityCons traintViolationE xception ex) {
                                      throw new LutadorDadoIncorret o("Já existe um lutador com " +
                                              "este documento no banco de dados");
                                  }

                          Pelo que li, poderia inclusive passar a MySQLIntegrityConst raintViolationEx ception como causa (está correto?) mas, pelo menos a princípio, não achei necessário.

                          Testei o funcionamento, quando tento qualquer operação que viole as regras de integridade do banco, esta exceção é lançada.

                          Valeu a ajuda Bruno.

                          []s,
                          Renato


                          Bruno Luiz Pereira da Silva escreveu:

                          Renato, o que você fez realmente te poupa um bom trabalho, e especialmente um trabalho bem chato se vc está usando jdbc diretamente para fazer o acesso ao banco de dados.
                          Entretanto, o que o Guilherme falou é verdade, esse acoplamento fica muito forte e te impede de reaproveitar a abordagem em outro banco de dados.
                          Uma solução que te permite deixar o controle de restrições de integridade para o banco sem te acoplar a um banco de dados específico é utilizar o controle de restrições de integridade da API jdbc.

                          Na versão 4 da API jdbc (disponível a partir do Java 6) temos uma exceção chamada SQLIntegrityConstra intViolationExce ption. Se você puder usar Java 6 na sua aplicação e tiver um driver jdbc suportando jdbc 4.0, você consegue ter o controle de restrições de integridade feito pelo banco de dados sem te acoplar a um banco específico.

                          Eu estou te falando isso apenas pelo conhecimento do recurso e da API, mas nunca cheguei a usar este recurso ainda. Acredito que os drivers da maioria dos bancos de dados mais comuns suporte isso bem, então é muito válido vc tentar trocar essa sua abordagem da exception específica do MySQL pela exception da API jdbc.

                          Se você conseguir testar isso, responda novamente aqui para que possamos saber sobre o funcionamento deste novo controle da API. O jdbc 4.0 trouxe algumas exceptions mais específicas do que SQLException, mas todas herdam de SQLException. É sempre bom conhecermos estes novos recursos para nos livrar de coisas como controle de restrições de integridade em código Java, o que é muito chato.

                          Espero ter ajudado.

                          --
                          Atenciosamente,

                          Bruno Luiz Pereira da Silva
                          blpsilva@gmail. com
                          http://brunopereira .com.br

                          2008/2/10 Guilherme Chapiewski <guilherme.chapiewsk i@...>:

                          O que você fez foi criar um alto acoplamento entre a sua aplicação e o banco de dados. Sua aplicação agora nunca mais vai poder trocar de banco de dados sem um refactoring gigantesco!

                          É uma boa prática não acoplar sua aplicação a nenhuma implementação de banco de dados específica.

                          Aí alguém pode falar: mas eu nunca ví uma aplicação trocar de banco de dados. E é verdade. Eu só ví uma vez. Mas a questão é que o esforço para desenvolver com e sem esse acoplamento é praticamente o mesmo, então acredito que valha a pena fazer da forma correta.

                          [ ]s, gc

                          --
                          Guilherme Chapiewski
                          http://gc.blog. br


                          Em 08/02/08, Renato Pinheiro de Souza <renato.pinheiro@ pobox.com> escreveu:

                          Oi Pessoal,

                          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, MySQLIntegrityConst raintViolationEx ception na camada de controle e repassando como causa dentro de uma exceção que criei.

                          Essa abordagem está correta? O código ficou muito mais limpo mas com isto eu transferi para o banco de dados um pouco da responsabilidade pela aplicação.

                          Atenciosamente,
                          Renato Pinheiro
                          www.gpi.ufrj. br



                          -=-=-=-=-=-= -=-=-=-=- =-=-=-=-= -=-=-=-=- =-=-
                          Rio Java Users Group: http://www.riojug. org
                          Moderadores: riojug-owner@ yahoogroups. com
                          -=-=-=-=-=-= -=-=-=-=- =-=-=-=-= -=-=-=-=- =-=-
                          Outras listas do RioJUG:
                          SCJP (groups.yahoo. com/group/ scjp_riojug)
                          SCWCD (groups.yahoo. com/group/ scwcd_riojug)
                          -=-=-=-=-=-= -=-=-=-=- =-=-=-=-= -=-=-=-=- =-=-
                          Yahoo! Finance

                          It's Now Personal

                          Guides, news,

                          advice & more.

                          New web site?

                          Drive traffic now.

                          Get your business

                          on Yahoo! search.

                          Yahoo! Groups

                          w/ John McEnroe

                          Join the All-Bran

                          Day 10 Club.

                          .
                          _._,___







                        • Bruno Luiz Pereira da Silva
                          Nem me fale... foi por isso que eu deixei de usar o e-mail do Yahoo. Eles levam a comunicação assíncrona mto a sério... as mensagens chegam dias depois :)
                          Message 12 of 14 , Mar 2, 2008
                            Nem me fale... foi por isso que eu deixei de usar o e-mail do Yahoo. Eles levam a comunicação assíncrona mto a sério... as mensagens chegam dias depois :)
                            O mesmo problema do Yahoo Mail rola no Yahoo Groups

                            2008/2/27 Renato Pinheiro de Souza <renato.pinheiro@...>:

                            Não prestei atenção, vou testar com a SQLIntegrityConstraintViolationException e dou notícias.

                            Em tempo, enviei a mensagem a muito tempo, não sei porque só chegou agora.

                            Att.,


                            Renato

                            Bruno Luiz Pereira da Silva escreveu:

                            Opa, o que eu tinha sugerido é que você troque o catch(MySQLIntegrityConstraintViolationException) por:
                            catch (SQLIntegrityConstraintViolationException).

                            Esta exception foi introduzida no Java 6, com a versão 4 do jdbc. Caso você tenha liberdade de usar Java 6 e um driver jdbc que suporte jdbc 4, você pode utilizar este catch. Ele te daria o mesmo recurso que vc tem ao usar a Exception específica do MySQL, mas sem te amarrar ao MySQL.

                            Você já tentou usar essa SQLIntegrityConstraintViolationException? Pela sua mensagem eu não entendi bem se você tinha tentado usar essa do Java 6 ou apenas a específica do MySQL. Se já usou a do Java 6, depois comenta os resultados então.

                             --
                            Atenciosamente,

                            Bruno Luiz Pereira da Silva
                            blpsilva@...
                            http://brunopereira.com.br

                            2008/2/10 Renato Pinheiro de Souza <renato.pinheiro@...>:

                            Oi Bruno,

                            foi exatamente essa exceção que utilizei, o código ficou assim:

                                    try{
                                        lutadorDAO.update(
                                                new Lutador( id, nome, equipeDAO.buscaEquipe(idEquipe),
                                                graduacao, gub, peso, idade, documento, email, sexo));
                                    } catch (MySQLIntegrityConstraintViolationException ex) {
                                        throw new LutadorDadoIncorreto("Já existe um lutador com " +
                                                "este documento no banco de dados");
                                    }

                            Pelo que li, poderia inclusive passar a MySQLIntegrityConstraintViolationException como causa (está correto?) mas, pelo menos a princípio, não achei necessário.

                            Testei o funcionamento, quando tento qualquer operação que viole as regras de integridade do banco, esta exceção é lançada.

                            Valeu a ajuda Bruno.

                            []s,
                            Renato


                            Bruno Luiz Pereira da Silva escreveu:

                            Renato, o que você fez realmente te poupa um bom trabalho, e especialmente um trabalho bem chato se vc está usando jdbc diretamente para fazer o acesso ao banco de dados.
                            Entretanto, o que o Guilherme falou é verdade, esse acoplamento fica muito forte e te impede de reaproveitar a abordagem em outro banco de dados.
                            Uma solução que te permite deixar o controle de restrições de integridade para o banco sem te acoplar a um banco de dados específico é utilizar o controle de restrições de integridade da API jdbc.

                            Na versão 4 da API jdbc (disponível a partir do Java 6) temos uma exceção chamada SQLIntegrityConstraintViolationException. Se você puder usar Java 6 na sua aplicação e tiver um driver jdbc suportando jdbc 4.0, você consegue ter o controle de restrições de integridade feito pelo banco de dados sem te acoplar a um banco específico.

                            Eu estou te falando isso apenas pelo conhecimento do recurso e da API, mas nunca cheguei a usar este recurso ainda. Acredito que os drivers da maioria dos bancos de dados mais comuns suporte isso bem, então é muito válido vc tentar trocar essa sua abordagem da exception específica do MySQL pela exception da API jdbc.

                            Se você conseguir testar isso, responda novamente aqui para que possamos saber sobre o funcionamento deste novo controle da API. O jdbc 4.0 trouxe algumas exceptions mais específicas do que SQLException, mas todas herdam de SQLException. É sempre bom conhecermos estes novos recursos para nos livrar de coisas como controle de restrições de integridade em código Java, o que é muito chato.

                            Espero ter ajudado.

                            --
                            Atenciosamente,

                            Bruno Luiz Pereira da Silva
                            blpsilva@...
                            http://brunopereira.com.br

                            2008/2/10 Guilherme Chapiewski <guilherme.chapiewski@...>:

                            O que você fez foi criar um alto acoplamento entre a sua aplicação e o banco de dados. Sua aplicação agora nunca mais vai poder trocar de banco de dados sem um refactoring gigantesco!

                            É uma boa prática não acoplar sua aplicação a nenhuma implementação de banco de dados específica.

                            Aí alguém pode falar: mas eu nunca ví uma aplicação trocar de banco de dados. E é verdade. Eu só ví uma vez. Mas a questão é que o esforço para desenvolver com e sem esse acoplamento é praticamente o mesmo, então acredito que valha a pena fazer da forma correta.

                            [ ]s, gc

                            --
                            Guilherme Chapiewski
                            http://gc.blog.br


                            Em 08/02/08, Renato Pinheiro de Souza <renato.pinheiro@...> escreveu:

                            Oi Pessoal,

                            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 que criei.

                            Essa abordagem está correta? O código ficou muito mais limpo mas com isto eu transferi para o banco de dados um pouco da responsabilidade pela aplicação.

                            Atenciosamente,
                            Renato Pinheiro
                            www.gpi.ufrj.br



                            -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
                            Rio Java Users Group: http://www.riojug.org
                            Moderadores: riojug-owner@yahoogroups.com
                            -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
                            Outras listas do RioJUG:
                            SCJP (groups.yahoo.com/group/scjp_riojug)
                            SCWCD (groups.yahoo.com/group/scwcd_riojug)
                            -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
                            Yahoo! Finance

                            It's Now Personal

                            Guides, news,

                            advice & more.

                            New web site?

                            Drive traffic now.

                            Get your business

                            on Yahoo! search.

                            Yahoo! Groups

                            w/ John McEnroe

                            Join the All-Bran

                            Day 10 Club.

                            .
                            _._,___










                            --
                            Atenciosamente,

                            Bruno Luiz Pereira da Silva
                            blpsilva@...
                            http://brunopereira.com.br
                          • Renato Pinheiro de Souza
                            Bruno, testei com as SQLIntegrityConstraintViolationException , funciona perfeitamente mas, o que tenho feito para desacoplar um pouco mais é encapsular em
                            Message 13 of 14 , Apr 4, 2008
                              Bruno, testei com as SQLIntegrityConstraintViolationException , funciona perfeitamente mas, o que tenho feito para desacoplar um pouco mais é encapsular em DAOExceptions.

                              Valeu a ajuda de todos!
                              []s,
                              Renato


                              2008/3/2 Bruno Luiz Pereira da Silva <blpsilva@...>:

                              Nem me fale... foi por isso que eu deixei de usar o e-mail do Yahoo. Eles levam a comunicação assíncrona mto a sério... as mensagens chegam dias depois :)
                              O mesmo problema do Yahoo Mail rola no Yahoo Groups

                              2008/2/27 Renato Pinheiro de Souza <renato.pinheiro@...>:

                              Não prestei atenção, vou testar com a SQLIntegrityConstraintViolationException e dou notícias.

                              Em tempo, enviei a mensagem a muito tempo, não sei porque só chegou agora.

                              Att.,


                              Renato

                              Bruno Luiz Pereira da Silva escreveu:

                              Opa, o que eu tinha sugerido é que você troque o catch(MySQLIntegrityConstraintViolationException) por:
                              catch (SQLIntegrityConstraintViolationException).

                              Esta exception foi introduzida no Java 6, com a versão 4 do jdbc. Caso você tenha liberdade de usar Java 6 e um driver jdbc que suporte jdbc 4, você pode utilizar este catch. Ele te daria o mesmo recurso que vc tem ao usar a Exception específica do MySQL, mas sem te amarrar ao MySQL.

                              Você já tentou usar essa SQLIntegrityConstraintViolationException? Pela sua mensagem eu não entendi bem se você tinha tentado usar essa do Java 6 ou apenas a específica do MySQL. Se já usou a do Java 6, depois comenta os resultados então.

                               --
                              Atenciosamente,

                              Bruno Luiz Pereira da Silva
                              blpsilva@...
                              http://brunopereira.com.br

                              2008/2/10 Renato Pinheiro de Souza <renato.pinheiro@...>:

                              Oi Bruno,

                              foi exatamente essa exceção que utilizei, o código ficou assim:

                                      try{
                                          lutadorDAO.update(
                                                  new Lutador( id, nome, equipeDAO.buscaEquipe(idEquipe),
                                                  graduacao, gub, peso, idade, documento, email, sexo));
                                      } catch (MySQLIntegrityConstraintViolationException ex) {
                                          throw new LutadorDadoIncorreto("Já existe um lutador com " +
                                                  "este documento no banco de dados");
                                      }

                              Pelo que li, poderia inclusive passar a MySQLIntegrityConstraintViolationException como causa (está correto?) mas, pelo menos a princípio, não achei necessário.

                              Testei o funcionamento, quando tento qualquer operação que viole as regras de integridade do banco, esta exceção é lançada.

                              Valeu a ajuda Bruno.

                              []s,
                              Renato


                              Bruno Luiz Pereira da Silva escreveu:

                              Renato, o que você fez realmente te poupa um bom trabalho, e especialmente um trabalho bem chato se vc está usando jdbc diretamente para fazer o acesso ao banco de dados.
                              Entretanto, o que o Guilherme falou é verdade, esse acoplamento fica muito forte e te impede de reaproveitar a abordagem em outro banco de dados.
                              Uma solução que te permite deixar o controle de restrições de integridade para o banco sem te acoplar a um banco de dados específico é utilizar o controle de restrições de integridade da API jdbc.

                              Na versão 4 da API jdbc (disponível a partir do Java 6) temos uma exceção chamada SQLIntegrityConstraintViolationException. Se você puder usar Java 6 na sua aplicação e tiver um driver jdbc suportando jdbc 4.0, você consegue ter o controle de restrições de integridade feito pelo banco de dados sem te acoplar a um banco específico.

                              Eu estou te falando isso apenas pelo conhecimento do recurso e da API, mas nunca cheguei a usar este recurso ainda. Acredito que os drivers da maioria dos bancos de dados mais comuns suporte isso bem, então é muito válido vc tentar trocar essa sua abordagem da exception específica do MySQL pela exception da API jdbc.

                              Se você conseguir testar isso, responda novamente aqui para que possamos saber sobre o funcionamento deste novo controle da API. O jdbc 4.0 trouxe algumas exceptions mais específicas do que SQLException, mas todas herdam de SQLException. É sempre bom conhecermos estes novos recursos para nos livrar de coisas como controle de restrições de integridade em código Java, o que é muito chato.

                              Espero ter ajudado.

                              --
                              Atenciosamente,

                              Bruno Luiz Pereira da Silva
                              blpsilva@...
                              http://brunopereira.com.br

                              2008/2/10 Guilherme Chapiewski <guilherme.chapiewski@...>:

                              O que você fez foi criar um alto acoplamento entre a sua aplicação e o banco de dados. Sua aplicação agora nunca mais vai poder trocar de banco de dados sem um refactoring gigantesco!

                              É uma boa prática não acoplar sua aplicação a nenhuma implementação de banco de dados específica.

                              Aí alguém pode falar: mas eu nunca ví uma aplicação trocar de banco de dados. E é verdade. Eu só ví uma vez. Mas a questão é que o esforço para desenvolver com e sem esse acoplamento é praticamente o mesmo, então acredito que valha a pena fazer da forma correta.

                              [ ]s, gc

                              --
                              Guilherme Chapiewski
                              http://gc.blog.br


                              Em 08/02/08, Renato Pinheiro de Souza <renato.pinheiro@...> escreveu:

                              Oi Pessoal,

                              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 que criei.

                              Essa abordagem está correta? O código ficou muito mais limpo mas com isto eu transferi para o banco de dados um pouco da responsabilidade pela aplicação.

                              Atenciosamente,
                              Renato Pinheiro
                              www.gpi.ufrj.br



                              -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
                              Rio Java Users Group: http://www.riojug.org
                              Moderadores: riojug-owner@yahoogroups.com
                              -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
                              Outras listas do RioJUG:
                              SCJP (groups.yahoo.com/group/scjp_riojug)
                              SCWCD (groups.yahoo.com/group/scwcd_riojug)
                              -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
                              Yahoo! Finance

                              It's Now Personal

                              Guides, news,

                              advice & more.

                              New web site?

                              Drive traffic now.

                              Get your business

                              on Yahoo! search.

                              Yahoo! Groups

                              w/ John McEnroe

                              Join the All-Bran

                              Day 10 Club.

                              .
                              _._,___










                              --
                              Atenciosamente,

                              Bruno Luiz Pereira da Silva
                              blpsilva@...
                              http://brunopereira.com.br



                              --
                              Atenciosamente,
                              Renato Pinheiro de Souza
                              renato.pinheiro@...
                              renato.pinheiro@...
                            Your message has been successfully submitted and would be delivered to recipients shortly.