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

Deixando um pouco de trabalho para o banco de dados

Expand Messages
  • Renato Pinheiro de Souza
    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
    Message 1 of 14 , Feb 8, 2008
    • 0 Attachment
      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
    • 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 2 of 14 , Feb 9, 2008
      • 0 Attachment
        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 3 of 14 , Feb 10, 2008
        • 0 Attachment
              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 4 of 14 , Feb 10, 2008
          • 0 Attachment
            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 5 of 14 , Feb 10, 2008
            • 0 Attachment
              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 6 of 14 , Feb 10, 2008
              • 0 Attachment
                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 7 of 14 , Feb 10, 2008
                • 0 Attachment
                  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 8 of 14 , Feb 11, 2008
                  • 0 Attachment
                    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 9 of 14 , Feb 15, 2008
                    • 0 Attachment
                      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 10 of 14 , Feb 15, 2008
                      • 0 Attachment
                        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 11 of 14 , Feb 27, 2008
                        • 0 Attachment
                          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 12 of 14 , Feb 27, 2008
                          • 0 Attachment
                            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 13 of 14 , Mar 2, 2008
                            • 0 Attachment
                              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 14 of 14 , Apr 4, 2008
                              • 0 Attachment
                                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.