Publicado em: 27/07/2012 09:34:50

Bom dia,
estava pesquisando sobre DefaultTableModel, e li muito dizendo para não o usar, ao invéz disso criar meu próprio TableModel. Isso prq dizem que o DefaulTableMode é custoso à desempenho, e um código que pode ficar muito dificil de manter.
meuTableModel tem quer ser um List de objetos de Clientes por exemplo.

A minha dúvia é, em uma seleção de clientes por exemplo, retorna muitos dados. colocar os dados de cada cliente retornado em um objeto, isso não é muito custoso em relação à desempenho? para programar é uma teta!

me deem uma luz por favor, estou perdido e parado com isso.
grato pela atenção, abraço.
_________________
Estudante de Sistemas de Informação FIPP-Unoeste 7º Termo
Os computadores são incrivelmente rápidos, precisos e burros; Os homens são incrivelmente lentos, imprecisos e brilhantes; Juntos, seus poderes ultrapassam os limites da imaginação.
- Albert Einstein

Publicado em: 27/07/2012 10:20:27

13alemao:

Bom dia,
estava pesquisando sobre DefaultTableModel, e li muito dizendo para não o usar, ao invéz disso criar meu próprio TableModel. Isso prq dizem que o DefaulTableMode é custoso à desempenho, e um código que pode ficar muito dificil de manter.
meuTableModel tem quer ser um List de objetos de Clientes por exemplo.

A minha dúvia é, em uma seleção de clientes por exemplo, retorna muitos dados. colocar os dados de cada cliente retornado em um objeto, isso não é muito custoso em relação à desempenho? para programar é uma teta!

me deem uma luz por favor, estou perdido e parado com isso.
grato pela atenção, abraço.

Eu discordo dessa afirmação de não usar o DefaultTableModel.
Se ele faz exatamente o que for necessário, eu o uso!

mas, por outro lado, é bastante fácil criar uma classe estendendo o AbstractTableModel. Quando comecei a fazer isso fiquei surpreso por ser mais simples do tinha pensado e, principalmente, por ficar muito fácil adaptar ele conforme desejado - algumas coisas acabaram funcionando quase que por sozinho...

Uma grande razão para não usar o DTM é quando o seu programa necessita armazenar os dados numa estrutura próprio causando a duplicação dos dados: sua estrutura e dentro do DTM.

Mas como eu disse, se ele fizer o que for necessário e não tiver que usar uma estrutura adicional para armazenar os dados, pode usar o DefaultTableModel!

Tudo EMO!
_________________
  Nome real: Carlos F. Heuberger

Removeram os meus direitos de administrador e moderador - sem aviso, pela segunda vez - contate o ombudsman (?), a equipejavafree ou a "alta gerência" se necessário - Que pena... que terminou dessa maneira!

"The mod javafree deserves, but not the one it needs right now."
--------------------
Não leio nem respondo MPs!
This posting is provided AS IS with no warranties and confers no rights.

Publicado em: 27/07/2012 10:30:47

simu:

13alemao:

Bom dia,
estava pesquisando sobre DefaultTableModel, e li muito dizendo para não o usar, ao invéz disso criar meu próprio TableModel. Isso prq dizem que o DefaulTableMode é custoso à desempenho, e um código que pode ficar muito dificil de manter.
meuTableModel tem quer ser um List de objetos de Clientes por exemplo.

A minha dúvia é, em uma seleção de clientes por exemplo, retorna muitos dados. colocar os dados de cada cliente retornado em um objeto, isso não é muito custoso em relação à desempenho? para programar é uma teta!

me deem uma luz por favor, estou perdido e parado com isso.
grato pela atenção, abraço.

Eu discordo dessa afirmação de não usar o DefaultTableModel.
Se ele faz exatamente o que for necessário, eu o uso!

mas, por outro lado, é bastante fácil criar uma classe estendendo o AbstractTableModel. Quando comecei a fazer isso fiquei surpreso por ser mais simples do tinha pensado e, principalmente, por ficar muito fácil adaptar ele conforme desejado - algumas coisas acabaram funcionando quase que por sozinho...

Uma grande razão para não usar o DTM é quando o seu programa necessita armazenar os dados numa estrutura próprio causando a duplicação dos dados: sua estrutura e dentro do DTM.

Mas como eu disse, se ele fizer o que for necessário e não tiver que usar uma estrutura adicional para armazenar os dados, pode usar o DefaultTableModel!

Tudo EMO!

valeu cara, eu já usava o DTM, nunca vi problema algum nos meus casos de uso, somente tive algumas dificuldades em implementar algo.
Agora que conheci, eu acho melhor criar meuTableModel vai ser muito mais simples.
Será que o sistema terá menos desempenho com isso cara?

valeu a atenção.

_________________
Estudante de Sistemas de Informação FIPP-Unoeste 7º Termo
Os computadores são incrivelmente rápidos, precisos e burros; Os homens são incrivelmente lentos, imprecisos e brilhantes; Juntos, seus poderes ultrapassam os limites da imaginação.
- Albert Einstein

Publicado em: 27/07/2012 11:43:12

13alemao:

simu:

[...]

valeu cara, eu já usava o DTM, nunca vi problema algum nos meus casos de uso, somente tive algumas dificuldades em implementar algo.
Agora que conheci, eu acho melhor criar meuTableModel vai ser muito mais simples.
Será que o sistema terá menos desempenho com isso cara?

valeu a atenção.

se não fizer um erro grave, o seu TableModel não vai ter desempenho pior, provavelmente vai ser melhor que o DTM... mas desempenho somente deve ser considerado em caso de problemas com ele...
_________________
  Nome real: Carlos F. Heuberger

Removeram os meus direitos de administrador e moderador - sem aviso, pela segunda vez - contate o ombudsman (?), a equipejavafree ou a "alta gerência" se necessário - Que pena... que terminou dessa maneira!

"The mod javafree deserves, but not the one it needs right now."
--------------------
Não leio nem respondo MPs!
This posting is provided AS IS with no warranties and confers no rights.

Publicado em: 27/07/2012 11:54:19

simu:

13alemao:

simu:

[...]

valeu cara, eu já usava o DTM, nunca vi problema algum nos meus casos de uso, somente tive algumas dificuldades em implementar algo.
Agora que conheci, eu acho melhor criar meuTableModel vai ser muito mais simples.
Será que o sistema terá menos desempenho com isso cara?

valeu a atenção.

se não fizer um erro grave, o seu TableModel não vai ter desempenho pior, provavelmente vai ser melhor que o DTM... mas desempenho somente deve ser considerado em caso de problemas com ele...

Ótimo saber disso, da uma olhada no codigo que fiz, copieui um pronto.
Fica muito tranquilo de usar.
Valeu pe ajuda, abraço.
package TablesModels; import Objetos.Telefone; import java.util.ArrayList; import java.util.List; import javax.swing.table.AbstractTableModel; public class Telefone_TableModel extends AbstractTableModel {     private static final long serialVersionUID = 1L;     /**      * Essa lista armazenará os objetos do tipo {@link Cliente} atualmente      * exibidos na tablela.      */     private List<Telefone> telefones;     // ==============================================================     // Construtores.     // ==============================================================     /**      * Constutor que simplesmente instancia o nosso {@link List} que usaremos      * para guardar os valores.      */     public Telefone_TableModel() {         // no construtor, instanciamos o List         telefones = new ArrayList<Telefone>();     }     /**      * Criamos um construtor de conveniência para já popular a lista.      *      * @param lista      *            a lista de clientes a ser adicionada.      */     public Telefone_TableModel(List<Telefone> lista) {         this();         telefones.addAll(lista);     }     // ==============================================================     // Métodos implementados.     // ==============================================================     @Override     public Class<?> getColumnClass(int coluna) {         // todas as colunas representam uma String         return String.class;     }     @Override     public int getColumnCount() {         return 5;//é a quantidade de colunas que tem na tabela     }     @Override     public String getColumnName(int coluna) {         switch (coluna) {         case 0:             return "ID_telefone";         case 1:             return "DDD";         case 2:             return "Numero";         case 3:             return "Tipo do telefone";         case 4:             return "ID_pessoa";         default:             return ""; // isso nunca deve ocorrer, pois temos só 3 colunas         }     }     @Override     public int getRowCount() {         return telefones.size();     }     @Override     public Object getValueAt(int linha, int coluna) {//retorna o valor da posição indicada         Telefone tel = telefones.get(linha);         switch (coluna) {         case 0:             return tel.getTel_id();         case 1:             return tel.getTel_ddd();         case 2:             return tel.getTel_numero();         case 3:             return tel.getTel_tipo();         case 4:             return tel.getPes_id();         default:             return null; // isso nunca deve ocorrer, pois temos só 5 colunas         }     }     @Override     public boolean isCellEditable(int rowIndex, int columnIndex) {         // nesse caso, todas as células são editáveis         return true;     }     @Override     public void setValueAt(Object valor, int linha, int coluna) { //colocar um valor na posição desejada         Telefone tel = telefones.get(linha);         switch (coluna) {         case 0:             tel.setTel_id(Integer.parseInt(valor.toString()));             break;         case 1:             tel.setTel_ddd(valor.toString());             break;         case 2:             tel.setTel_numero(valor.toString());         case 3:             tel.setTel_tipo(valor.toString());         case 4:             tel.setPes_id(Integer.parseInt(valor.toString()));             break;         }         // é importante notificar os listeners a cada alteração         fireTableDataChanged();     }     // ==============================================================     // Até aqui seria o mínimo necessário para um TableModel funcional, mas     // ainda não há métodos para adicionar, remover ou resgatar objetos. Vamos     // criá-los.     // ==============================================================     /**      * Adiciona um novo {@link Cliente} e notifica os listeners que um novo      * registro foi adicionado.      */     public void adiciona(Telefone tel) {         telefones.add(tel);         // informamos os listeners que a linha (size - 1) foi adicionada         fireTableRowsInserted(telefones.size() - 1, telefones.size() - 1);     }     /**      * Similar ao {@link #adiciona(Cliente)}, porém para remover. Recebe o      * índice do cliente a ser removido. Se não souber o índice, use o método      * {@link #getIndice(Cliente)} antes.      */     public void remove(int indice) {         telefones.remove(indice);         fireTableRowsDeleted(indice, indice);     }     /**      * Retorna o índice de determinado cliente.      */     public int getIndice(Telefone c) {         return telefones.indexOf(c);     }     /**      * Adiciona todos os clientes na lista à este modelo.      */     public void adicionaLista(List<Telefone> lista) {         int i = telefones.size();         telefones.addAll(lista);         fireTableRowsInserted(i, i + lista.size());     }     /**      * Esvazia a lista.      */     public void limpaLista() {         int i = telefones.size();         telefones.clear();         fireTableRowsDeleted(0, i - 1);     } }
_________________
Estudante de Sistemas de Informação FIPP-Unoeste 7º Termo
Os computadores são incrivelmente rápidos, precisos e burros; Os homens são incrivelmente lentos, imprecisos e brilhantes; Juntos, seus poderes ultrapassam os limites da imaginação.
- Albert Einstein

Publicado em: 27/07/2012 16:20:21

13alemao:

simu:

[...]

Ótimo saber disso, da uma olhada no codigo que fiz, copieui um pronto.
Fica muito tranquilo de usar.
Valeu pe ajuda, abraço.
package TablesModels; import Objetos.Telefone; import java.util.ArrayList; import java.util.List; import javax.swing.table.AbstractTableModel; public class Telefone_TableModel extends AbstractTableModel {     private static final long serialVersionUID = 1L;     /**      * Essa lista armazenará os objetos do tipo {@link Cliente} atualmente      * exibidos na tablela.      */     private List<Telefone> telefones;     // ==============================================================     // Construtores.     // ==============================================================     /**      * Constutor que simplesmente instancia o nosso {@link List} que usaremos      * para guardar os valores.      */     public Telefone_TableModel() {         // no construtor, instanciamos o List         telefones = new ArrayList<Telefone>();     }     /**      * Criamos um construtor de conveniência para já popular a lista.      *      * @param lista      *            a lista de clientes a ser adicionada.      */     public Telefone_TableModel(List<Telefone> lista) {         this();         telefones.addAll(lista);     }     // ==============================================================     // Métodos implementados.     // ==============================================================     @Override     public Class<?> getColumnClass(int coluna) {         // todas as colunas representam uma String         return String.class;     }     @Override     public int getColumnCount() {         return 5;//é a quantidade de colunas que tem na tabela     }     @Override     public String getColumnName(int coluna) {         switch (coluna) {         case 0:             return "ID_telefone";         case 1:             return "DDD";         case 2:             return "Numero";         case 3:             return "Tipo do telefone";         case 4:             return "ID_pessoa";         default:             return ""; // isso nunca deve ocorrer, pois temos só 3 colunas         }     }     @Override     public int getRowCount() {         return telefones.size();     }     @Override     public Object getValueAt(int linha, int coluna) {//retorna o valor da posição indicada         Telefone tel = telefones.get(linha);         switch (coluna) {         case 0:             return tel.getTel_id();         case 1:             return tel.getTel_ddd();         case 2:             return tel.getTel_numero();         case 3:             return tel.getTel_tipo();         case 4:             return tel.getPes_id();         default:             return null; // isso nunca deve ocorrer, pois temos só 5 colunas         }     }     @Override     public boolean isCellEditable(int rowIndex, int columnIndex) {         // nesse caso, todas as células são editáveis         return true;     }     @Override     public void setValueAt(Object valor, int linha, int coluna) { //colocar um valor na posição desejada         Telefone tel = telefones.get(linha);         switch (coluna) {         case 0:             tel.setTel_id(Integer.parseInt(valor.toString()));             break;         case 1:             tel.setTel_ddd(valor.toString());             break;         case 2:             tel.setTel_numero(valor.toString());         case 3:             tel.setTel_tipo(valor.toString());         case 4:             tel.setPes_id(Integer.parseInt(valor.toString()));             break;         }         // é importante notificar os listeners a cada alteração         fireTableDataChanged();     }     // ==============================================================     // Até aqui seria o mínimo necessário para um TableModel funcional, mas     // ainda não há métodos para adicionar, remover ou resgatar objetos. Vamos     // criá-los.     // ==============================================================     /**      * Adiciona um novo {@link Cliente} e notifica os listeners que um novo      * registro foi adicionado.      */     public void adiciona(Telefone tel) {         telefones.add(tel);         // informamos os listeners que a linha (size - 1) foi adicionada         fireTableRowsInserted(telefones.size() - 1, telefones.size() - 1);     }     /**      * Similar ao {@link #adiciona(Cliente)}, porém para remover. Recebe o      * índice do cliente a ser removido. Se não souber o índice, use o método      * {@link #getIndice(Cliente)} antes.      */     public void remove(int indice) {         telefones.remove(indice);         fireTableRowsDeleted(indice, indice);     }     /**      * Retorna o índice de determinado cliente.      */     public int getIndice(Telefone c) {         return telefones.indexOf(c);     }     /**      * Adiciona todos os clientes na lista à este modelo.      */     public void adicionaLista(List<Telefone> lista) {         int i = telefones.size();         telefones.addAll(lista);         fireTableRowsInserted(i, i + lista.size());     }     /**      * Esvazia a lista.      */     public void limpaLista() {         int i = telefones.size();         telefones.clear();         fireTableRowsDeleted(0, i - 1);     } }

acho que eu não faria diferente.
O que eventualmente (dificilmente?) pode dar dor de cabeça é a falta de sincronização da lista. Se os dados somente forem manipulados dentro da Thread da GUI, não vai ser problema... e mesmo caso contrário, vai ser difícil perceber algum erro.
_________________
  Nome real: Carlos F. Heuberger

Removeram os meus direitos de administrador e moderador - sem aviso, pela segunda vez - contate o ombudsman (?), a equipejavafree ou a "alta gerência" se necessário - Que pena... que terminou dessa maneira!

"The mod javafree deserves, but not the one it needs right now."
--------------------
Não leio nem respondo MPs!
This posting is provided AS IS with no warranties and confers no rights.

Publicado em: 27/07/2012 16:33:39


Ei... você está usando DefaultTableModel no seu projeto??
Não faça isso!
DefaultTableModel é a implementação concreta padrão de TableModel usada por JTable quando nenhum modelo é especificado no construtor. Esta classe uma um Vector de Vectors para gerenciar seus dados, o que torna a implementação de AbstractTableModel uma escolha mais adequada (AbstractTableModel permite controle completo sobre como a armazenagem e manipulação dos dados são implementadas). Este Vector pode ser atribuido com o método sobrecarregado setDataVector(), e obtido com o método getDataVector(). Internamente, dois métodos convertToVector() sobrecarregados e protegidos são usados para converter matrizes de Object em Vectors quando linhas e colunas são adicionadas ou um novo Vector é atribuido. Métodos para adição, inserção, exclusão, mover colunas e linhas de dados também são fornecidos



1. É mais difícil que escrever seu próprio TableModel;
2. É mais lento (usa classes sincronizadas);
3. Ocupa mais espaço em memória (duplica seus dados);
4. Deixa o código mais confuso e difícil de manter;
5. Usa casts inseguros;
6. Força que você tenha que exibir informações desnecessárias (como o ID) na tabela, ou controlar o ID numa lista separada;
7. Faz a sua mulher te deixar, o leite da sua geladeira azedar, e pessoas apontarem o dedo para você na rua.

simu:

13alemao:

Bom dia,
estava pesquisando sobre DefaultTableModel, e li muito dizendo para não o usar, ao invéz disso criar meu próprio TableModel. Isso prq dizem que o DefaulTableMode é custoso à desempenho, e um código que pode ficar muito dificil de manter.
meuTableModel tem quer ser um List de objetos de Clientes por exemplo.

A minha dúvia é, em uma seleção de clientes por exemplo, retorna muitos dados. colocar os dados de cada cliente retornado em um objeto, isso não é muito custoso em relação à desempenho? para programar é uma teta!

me deem uma luz por favor, estou perdido e parado com isso.
grato pela atenção, abraço.

Eu discordo dessa afirmação de não usar o DefaultTableModel.
Se ele faz exatamente o que for necessário, eu o uso!

mas, por outro lado, é bastante fácil criar uma classe estendendo o AbstractTableModel. Quando comecei a fazer isso fiquei surpreso por ser mais simples do tinha pensado e, principalmente, por ficar muito fácil adaptar ele conforme desejado - algumas coisas acabaram funcionando quase que por sozinho...

Uma grande razão para não usar o DTM é quando o seu programa necessita armazenar os dados numa estrutura próprio causando a duplicação dos dados: sua estrutura e dentro do DTM.

Mas como eu disse, se ele fizer o que for necessário e não tiver que usar uma estrutura adicional para armazenar os dados, pode usar o DefaultTableModel!

Tudo EMO!

Publicado em: 27/07/2012 16:36:00

paulinho!!!:

Ei... você está usando DefaultTableModel no seu projeto??
Não faça isso!
DefaultTableModel é a implementação concreta padrão de TableModel usada por JTable quando nenhum modelo é especificado no construtor. Esta classe uma um Vector de Vectors para gerenciar seus dados, o que torna a implementação de AbstractTableModel uma escolha mais adequada (AbstractTableModel permite controle completo sobre como a armazenagem e manipulação dos dados são implementadas). Este Vector pode ser atribuido com o método sobrecarregado setDataVector(), e obtido com o método getDataVector(). Internamente, dois métodos convertToVector() sobrecarregados e protegidos são usados para converter matrizes de Object em Vectors quando linhas e colunas são adicionadas ou um novo Vector é atribuido. Métodos para adição, inserção, exclusão, mover colunas e linhas de dados também são fornecidos

1. É mais difícil que escrever seu próprio TableModel;
2. É mais lento (usa classes sincronizadas);
3. Ocupa mais espaço em memória (duplica seus dados);
4. Deixa o código mais confuso e difícil de manter;
5. Usa casts inseguros;
6. Força que você tenha que exibir informações desnecessárias (como o ID) na tabela, ou controlar o ID numa lista separada;
7. Faz a sua mulher te deixar, o leite da sua geladeira azedar, e pessoas apontarem o dedo para você na rua.

simu:

13alemao:

Bom dia,
estava pesquisando sobre DefaultTableModel, e li muito dizendo para não o usar, ao invéz disso criar meu próprio TableModel. Isso prq dizem que o DefaulTableMode é custoso à desempenho, e um código que pode ficar muito dificil de manter.
meuTableModel tem quer ser um List de objetos de Clientes por exemplo.

A minha dúvia é, em uma seleção de clientes por exemplo, retorna muitos dados. colocar os dados de cada cliente retornado em um objeto, isso não é muito custoso em relação à desempenho? para programar é uma teta!

me deem uma luz por favor, estou perdido e parado com isso.
grato pela atenção, abraço.

Eu discordo dessa afirmação de não usar o DefaultTableModel.
Se ele faz exatamente o que for necessário, eu o uso!

mas, por outro lado, é bastante fácil criar uma classe estendendo o AbstractTableModel. Quando comecei a fazer isso fiquei surpreso por ser mais simples do tinha pensado e, principalmente, por ficar muito fácil adaptar ele conforme desejado - algumas coisas acabaram funcionando quase que por sozinho...

Uma grande razão para não usar o DTM é quando o seu programa necessita armazenar os dados numa estrutura próprio causando a duplicação dos dados: sua estrutura e dentro do DTM.

Mas como eu disse, se ele fizer o que for necessário e não tiver que usar uma estrutura adicional para armazenar os dados, pode usar o DefaultTableModel!

Tudo EMO!

Publicado em: 27/07/2012 18:16:12

paulinho!!!:

Ei... você está usando DefaultTableModel no seu projeto??
Não faça isso!
DefaultTableModel é a implementação concreta padrão de TableModel usada por JTable quando nenhum modelo é especificado no construtor. Esta classe uma um Vector de Vectors para gerenciar seus dados, o que torna a implementação de AbstractTableModel uma escolha mais adequada (AbstractTableModel permite controle completo sobre como a armazenagem e manipulação dos dados são implementadas). Este Vector pode ser atribuido com o método sobrecarregado setDataVector(), e obtido com o método getDataVector(). Internamente, dois métodos convertToVector() sobrecarregados e protegidos são usados para converter matrizes de Object em Vectors quando linhas e colunas são adicionadas ou um novo Vector é atribuido. Métodos para adição, inserção, exclusão, mover colunas e linhas de dados também são fornecidos



1. É mais difícil que escrever seu próprio TableModel;
2. É mais lento (usa classes sincronizadas);
3. Ocupa mais espaço em memória (duplica seus dados);
4. Deixa o código mais confuso e difícil de manter;
5. Usa casts inseguros;
6. Força que você tenha que exibir informações desnecessárias (como o ID) na tabela, ou controlar o ID numa lista separada;
7. Faz a sua mulher te deixar, o leite da sua geladeira azedar, e pessoas apontarem o dedo para você na rua.

simu:

Eu discordo dessa afirmação de não usar o DefaultTableModel.
Se ele faz exatamente o que for necessário, eu o uso!

[...]

1. pelo contrário (assumindo o que escrevi antes: "Se ele faz exatamente o que for necessário")

2. só vai ser (pouco) mais lento para MUITOS dados e MUITA alteração do conteúdo (difícil ser o caso para uma JTable)

3. não se armazenar os dados apenas no DTM

4. pelo contrário ("Se ele faz exatamente o que for necessário")

5. e dai? argumento muito fraco para - se o programador colocar um elemento do tipo errado , a tabela vai mostrar um elemento errado

6. ponto válido, mas não "Se ele faz exatamente o que for necessário"

7. OK, diz tudo!

(Déjà vu - só porque alguém (?) escreveu isso na rede não é lei)
(acredito que esse pontos nem são de sua autoria... deveriam ser marcados de acordo...)

normalmente também prefiro fazer o meu modelo, mas existem (poucas) situações onde é mais fácil/rápido usar o DTM...

again tudo EMO
_________________
  Nome real: Carlos F. Heuberger

Removeram os meus direitos de administrador e moderador - sem aviso, pela segunda vez - contate o ombudsman (?), a equipejavafree ou a "alta gerência" se necessário - Que pena... que terminou dessa maneira!

"The mod javafree deserves, but not the one it needs right now."
--------------------
Não leio nem respondo MPs!
This posting is provided AS IS with no warranties and confers no rights.

Publicado em: 28/07/2012 13:20:33

OK, que sirva para outros essa lição também.
E qual seria uma forma eficiente e eficaz de fazer isso, considerando um grande numero de dados retornado da base de dados?
_________________
Estudante de Sistemas de Informação FIPP-Unoeste 7º Termo
Os computadores são incrivelmente rápidos, precisos e burros; Os homens são incrivelmente lentos, imprecisos e brilhantes; Juntos, seus poderes ultrapassam os limites da imaginação.
- Albert Einstein

Publicado em: 28/07/2012 13:23:40

simu:

paulinho!!!:

Ei... você está usando DefaultTableModel no seu projeto??
Não faça isso!
DefaultTableModel é a implementação concreta padrão de TableModel usada por JTable quando nenhum modelo é especificado no construtor. Esta classe uma um Vector de Vectors para gerenciar seus dados, o que torna a implementação de AbstractTableModel uma escolha mais adequada (AbstractTableModel permite controle completo sobre como a armazenagem e manipulação dos dados são implementadas). Este Vector pode ser atribuido com o método sobrecarregado setDataVector(), e obtido com o método getDataVector(). Internamente, dois métodos convertToVector() sobrecarregados e protegidos são usados para converter matrizes de Object em Vectors quando linhas e colunas são adicionadas ou um novo Vector é atribuido. Métodos para adição, inserção, exclusão, mover colunas e linhas de dados também são fornecidos



1. É mais difícil que escrever seu próprio TableModel;
2. É mais lento (usa classes sincronizadas);
3. Ocupa mais espaço em memória (duplica seus dados);
4. Deixa o código mais confuso e difícil de manter;
5. Usa casts inseguros;
6. Força que você tenha que exibir informações desnecessárias (como o ID) na tabela, ou controlar o ID numa lista separada;
7. Faz a sua mulher te deixar, o leite da sua geladeira azedar, e pessoas apontarem o dedo para você na rua.

simu:

Eu discordo dessa afirmação de não usar o DefaultTableModel.
Se ele faz exatamente o que for necessário, eu o uso!

[...]

1. pelo contrário (assumindo o que escrevi antes: "Se ele faz exatamente o que for necessário")

2. só vai ser (pouco) mais lento para MUITOS dados e MUITA alteração do conteúdo (difícil ser o caso para uma JTable)

3. não se armazenar os dados apenas no DTM

4. pelo contrário ("Se ele faz exatamente o que for necessário")

5. e dai? argumento muito fraco para - se o programador colocar um elemento do tipo errado , a tabela vai mostrar um elemento errado

6. ponto válido, mas não "Se ele faz exatamente o que for necessário"

7. OK, diz tudo!

(Déjà vu - só porque alguém (?) escreveu isso na rede não é lei)
(acredito que esse pontos nem são de sua autoria... deveriam ser marcados de acordo...)

normalmente também prefiro fazer o meu modelo, mas existem (poucas) situações onde é mais fácil/rápido usar o DTM...

again tudo EMO

Simu, eu uso o DTM em uma aplicação que fiz, e não tive nenhum problema, e já faz um tempo que o implantei. Contudo a base de dados do meu cliente não tem muita coisa, não sei se isso seria um motivo para ficar lento ou algo assim. Só foi um pouco mais trabalhoso para implementar, mas funciona. grato.
_________________
Estudante de Sistemas de Informação FIPP-Unoeste 7º Termo
Os computadores são incrivelmente rápidos, precisos e burros; Os homens são incrivelmente lentos, imprecisos e brilhantes; Juntos, seus poderes ultrapassam os limites da imaginação.
- Albert Einstein

### jTable ###
http://javafree.uol.com.br/topic-12479-jTable.html

Criando Uma Janela Diferenciada [RESOLVIDO]
http://javafree.uol.com.br/topic-868537-Criando-Uma-Janela-Diferenciada-RESOLVIDO.html

Duvida sobre TableModel
http://javafree.uol.com.br/topic-868174-Duvida-sobre-TableModel.html

[Resolvido] Excluir/Incluir linhas em uma JTable no netbeans
http://javafree.uol.com.br/topic-886808-Resolvido-Excluir-Incluir-linhas-em-uma-JTable-no-netbeans.html

Como faço para adicionar uma nova linha numa JTAble?
http://javafree.uol.com.br/topic-13727-Como-faco-para-adicionar-uma-nova-linha-numa-JTAble.html

Atribuir valores Vetor para Jtable
http://javafree.uol.com.br/topic-886870-Atribuir-valores-Vetor-para-Jtable.html

Primeira linha da tabela
http://javafree.uol.com.br/topic-882226-Primeira-linha-da-tabela.html

Tabela
http://javafree.uol.com.br/topic-878845-Tabela.html

Adicionar imagem no JTable
http://javafree.uol.com.br/topic-879846-Adicionar-imagem-no-JTable.html