Fórum Consulta - Jtable #3846

Pirahy,
o consultor não tem acesso ao seu disco virtual. Vc tem que enviar o caminho completo para que ele possa baixar. Por favor,clique com o botão direito do mouse sobre o arquivo e escolha a opção copiar link.

https://www.devmedia.com.br/imagens/discovirtual/200408/FNT_J.rar

Olá Pirahy,

bem: vamos por partes então, ok?

Bem, visto que o código que você me enviou é bem grandinho (são diversas classes), dei uma olhada por alto e identifiquei alguns pontos que você realmente poderá melhorar (e MUITO) a sua produtividade. Vamos a eles:

Por exemplo: em TributacaoControl, você tem expressões SQL como

String cadastraTributacao = "INSERT INTO agr.\"ATRIBUT\" (\"TRIB_EMPRESA\", \"TRIB_OPER\", \"TRIB_EMP_PROD\", \"TRIB_PROD\", \"TRIB_UF\"" +
            ",\"TRIB_TIPO\",\"TRIB_ALIQ_IPI\",\"TRIB_COD_OBS\",\"TRIB_ST_A\",\"TRIB_ST_B\",\"TRIB_CFOP\",\"TRIB_OBS_GIAO\",\"TRIB_OBS_GIA\"" +
            ",\"TRIB_COD_ICM\",\"TRIB_PAUTA\",\"TRIB_IRRF\",\"TRIB_BLOQUEADA\")" +
            " VALUES (?,?,?,?,? ,?,?,?,?,?,?,?,?,?,?,?,?)";

É bacana usar uma ou outra instrução SQL nas suas consultas, no entanto, a coisa começa a se complicar na medida em que vamos tendo de trabalhar com mais e mais filtros. Nestes casos, é muito comum acabar caindo em uma das maiores ciladas que o programador pode se meter: concatenação de strings para se fazer consultas a um banco de dados.

E outra: confusão na ordem dos parâmetros também. Perceba a quantidade de parametros na consulta que citei acima: a manutenção do código fica bastante complexa, não é mesmo? Errou a ordem de um parametro e pronto: encontrar o erro lhe custará um bom tempo.

A melhor coisa a se fazer nestes casos consiste em abandonar a abordagem tradicional de acesso ao SGBD, que consiste na utilização de instruções SQL e passar para a utilização de alguma ferramenta de mapeamento objeto relacional (conhecidas como ORM: Object Relational Mapping) , como por exemplo o Hibernate e o Toplink.

(dentre os dois, minha sugestão é o Hibernate, pois é 100% livre, além de possuir documentação muito mais rica em comparação ao Toplink da Oracle)

O que estas ferramentas fazem: basicamente, livram o programador do SQL, que pode ser um verdadeiro martírio, uma vez que após ter sido feita a busca no banco de dados, você precisa transformar os dados que inicialmente se encontram armazenados em linhas e colunas para valores de atributos presentes em um objeto. Neste caso, o ORM fará exatamente isto: ele irá mapear de maneira automática cada campo do banco de dados a um dos atributos presentes em suas classes. Neste processo, irá executar para você tarefas tediosas, como por exemplo popular instancias de suas classes e alterar dados presentes no banco de dados.

Códigos como o que encontrei abaixo, por exemplo:

 if (rs.next()) {
                prod = new TributacaoBean();
                prod.setEmpresa(rs.getInt("TRIB_EMPRESA"));
                prod.setOper(rs.getInt("TRIB_OPER"));
                prod.setUf(rs.getString("TRIB_UF"));
                prod.setEmp_prod(rs.getInt("TRIB_EMP_PROD"));
                prod.setProd(rs.getInt("TRIB_PROD"));
                prod.setTipo(rs.getString("TRIB_TIPO"));
                prod.setAliq_ipi(rs.getDouble("TRIB_ALIQ_IPI"));
                prod.setCod_obs(rs.getInt("TRIB_COD_OBS"));
                prod.setSt_a(rs.getInt("TRIB_ST_A"));
                prod.setSt_b(rs.getInt("TRIB_ST_B"));
                prod.setCfop(rs.getDouble("TRIB_CFOP"));
                prod.setObs_giao(rs.getInt("TRIB_OBS_GIAO"));
                prod.setObs_gia(rs.getInt("TRIB_OBS_GIA"));
                prod.setCod_icm(rs.getInt("TRIB_COD_ICM"));
                prod.setPauta(rs.getBoolean("TRIB_PAUTA"));
                prod.setIrrf(rs.getInt("TRIB_IRRF"));
                prod.setBloqueada(rs.getBoolean("TRIB_BLOQUEADA"));
                if (rs.getString("COD_TIPO").equals("T")) {
                    prod.setIcm_tipo(1);
                } else if (rs.getString("COD_TIPO").equals("I")) {
                    prod.setIcm_tipo(2);
                } else if (rs.getString("COD_TIPO").equals("E")) {
                    prod.setIcm_tipo(4);
                } else {
                    prod.setIcm_tipo(3);
                }
                //T=TRIBUTADO - I=ISENTO - D=DIFERIDO - E=EXCLUIDO GIAO
                prod.setIcm_descricao(rs.getString("COD_DESCRICAO"));
                prod.setIcm_aliquota(rs.getDouble("COD_ALIQUOTA"));
                prod.setIcm_perc_redu(rs.getDouble("COD_PERC_REDU"));
            }

poderiam ser substituidos por duas ou três linhas (às vezes até uma!)! Como resultado, sua produtividade aumentará significativamente, assim como também diminuirá a possibilidade de erros cometidos pelo desenvolvedor.

Uma dúvida que pode aparecer aqui é: se as consultas são geradas de forma automática, não seriam elas lentas? Na realidade, aqui entra um fato surpreendente: não! O próprio ORM já otimiza as consultas para você de acordo com o SGBD que você escolha para trabalhar!

Outra grande vantagem destas ferramentas, é que elas podem inclusive gerar a base de dados para você automáticamente. Assim você só terá de se preocupar com suas classes, não com a estrutura das tabelas presentes no SGBD. Grails (http://grails.org) por exemplo utiliza este recurso o tempo inteiro.


Agora, com relação a table models, que foi o título deste chamado. Percebi no seu código que você utiliza o DefaultTableModel como table model do seu componente JTable. Esta não é a melhor opção. Neste caso, a melhor opção seria que você construísse o seu próprio table model, pois assim poderia otimizar o seu código para cada caso. Para tal, basta escrever uma classe que extenda javax.swing.table.AbstractTableModel.

(No caso do DefaultTableModel, ele trabalha apenas com matrizes, que nem sempre são populadas da maneira mais eficiente).

Não entendi 100% a questão de usar um proprio table model, como ficaria, tens um exemplo?

Olá Pirahy,

A questão de se usar o seu próprio table model é a seguinte: quando você utiliza um DefaultTableModel, este está na realidade representando dados que se encontram dentro de uma matriz.

Em um primeiro momento, parece ser uma opção bem bacana de se usar, uma vez que é fácil de se implementar. E realmente é: basta utilizar a implementação já pronta que a própria plataforma Java oferece.

No entanto, esta alternativa vem com alguns problemas:

1. Não há muito como customizar o modo como os dados serão expostos na tabela. Você só terá controle sobre a matriz que armazena objetos do tipo Object que deseja expor. Se quiser por exemplo utilizar alguma regra de exposição, não conseguirá.

2. Não é muito fácil de se otimizar o modo como o conteúdo será buscado e, em seguida, exposto para o usuário.

Sendo assim, a melhor opção (apesar de um pouco mais trabalhosa) consiste no desenvolvedor implementar o seu próprio table model. Para tal, o caminho mais fácil consiste em criar uma nova classe que seja filha de javax.swing.table.AbstractTableModel.

Mais detalhes sobre como fazê-lo encontram-se no link abaixo:
http://java.sun.com/docs/books/tutorial/uiswing/components/table.html

Pirahy,

como não houve respostas a este tópico por mais de dois dias, o mesmo será fechado.

Precisando de qualquer coisa, estamos a disposição.