| Autor |
Mensagem |
![[Post New]](/templates/default/images/icon_minipost_new.gif) 05/11/2007 16:52:15
|
bonfarj
Java Ninja
![[Avatar]](/images/avatar/1454ca2270599546dfcd2a3700e4d2f1.jpg)
Membro desde: 28/03/2006 09:55:47
Mensagens: 298
Offline
|
Imaginem uma classe Pessoa, com os atributos nome e idade. Para cada objeto da classe Pessoa eu gostaria de ter um histórico com todas as modificações, um atributo List<PessoaItemHistorico> historico. Essa classe PessoaItemHistorico poderia implementar a interface ItemHistorico, que obrigaria a implementação de getters e setters de atributos em comum como usuário que fez a modificação do objeto, data da modificação. Poderíamos também pensar na criação de uma outra interface, algo como Historiavel (eu não achei um nome melhor ), que obrigari a classe a implementar um método getItensHistorico().
Vocês estão de acordo com este modelo? Existe algum tipo de padrão para situações desse tipo?
Fora essa questão, estou particularmente preocupado com o modelo físico do banco de dados, pois mantenho duas tabelas (imaginem "pessoa" e "pessoahistorico"). Se eu precisar mudar o tipo de dado da coluna "nome" de VARCHAR(40) para VARCHAR(100) tenho que lembrar de mudar nas duas tabelas, caso contrário terei problemas na inserção de registros com mais de 40 caracteres. Para eliminar esse problema, pensei em deixar ambos os campos com VARCHAR(255) e tratar o limite de caracteres via código (o tamanho atualmente só é validado na camada de Visão), mas isso não resolve todo o problema. Alguém tem alguma sugestão para isso?
Abraços a todos!
|
IGOR BRITO ALVES
@igoralves
|
|
|
 |
|
|
![[Post New]](/templates/default/images/icon_minipost_new.gif) 06/11/2007 08:17:12
|
Ferryman
JavaGuru
![[Avatar]](/images/avatar/2e3907cbad887e6a1bea84d450b756db.jpg)
Membro desde: 26/10/2006 16:30:23
Mensagens: 220
Offline
|
Eai cara,
Estou sem muito tempo pra ajudar agora, mas procure ler sobre o design pattern memento. Ele pode te ajudar com isso.
[]s
Ferry
|
Rafael Farias Silva (@rafaferry)
Jsigner - Engenharia reversa automática através do maven. Acesse http://code.google.com/p/jsigner |
|
|
 |
![[Post New]](/templates/default/images/icon_minipost_new.gif) 06/11/2007 08:28:10
|
sergiotaborda
GUJ Expert
![[Avatar]](/images/avatar/b4a0e0fbaa9f16d8947c49f4e610b549.png)
Membro desde: 22/03/2005 20:57:48
Mensagens: 3433
Offline
|
bonfarj wrote:Imaginem uma classe Pessoa, com os atributos nome e idade. Para cada objeto da classe Pessoa eu gostaria de ter um histórico com todas as modificações, um atributo List<PessoaItemHistorico> historico. Essa classe PessoaItemHistorico poderia implementar a interface ItemHistorico, que obrigaria a implementação de getters e setters de atributos em comum como usuário que fez a modificação do objeto, data da modificação. Poderíamos também pensar na criação de uma outra interface, algo como Historiavel (eu não achei um nome melhor  ), que obrigari a classe a implementar um método getItensHistorico().
Vocês estão de acordo com este modelo? Existe algum tipo de padrão para situações desse tipo?
Sim, existe. E é esse mesmo. Mas com um detalhes.
A classe Pessoa sempre representa o item tal como ele é hoje e HistoricoPessoa sempre representa a pessoa como ela era numa certa data. Logo, para obter HistoricoPessoa para uma certa data o padrão é assim:
hp é o historico da pessoa , ou seja, são os dados de p mas no dia que não hoje. Portanto
HistoricoPessoa é tb uma pessoa. Historico tem uma data. O usuário que fez a alteração é um dado optional do historico.
dê uma olhada tb em:
http://martinfowler.com/eaaDev/Snapshot.html
Fora essa questão, estou particularmente preocupado com o modelo físico do banco de dados, pois mantenho duas tabelas (imaginem "pessoa" e "pessoahistorico"). Se eu precisar mudar o tipo de dado da coluna "nome" de VARCHAR(40) para VARCHAR(100) tenho que lembrar de mudar nas duas tabelas, caso contrário terei problemas na inserção de registros com mais de 40 caracteres. Para eliminar esse problema, pensei em deixar ambos os campos com VARCHAR(255) e tratar o limite de caracteres via código (o tamanho atualmente só é validado na camada de Visão), mas isso não resolve todo o problema. Alguém tem alguma sugestão para isso?
Realmente esse problema existe. vc tem várias opções mas nenhuma é à prova de bala
1) Dimensionar o seu campo corretamente para que não seja necessário mudar depois.
2) Corrigir ambos na mão quando necessário
3) Usar uma mecanismo de metadados que extrapole os metadados da tabela de historico baseado nos metadados da tabela original + metadados necessários para historico. Esta opção pode aumentar muito a sua infraestrutura. Uma variação deste mecanismo seria usar uma tabela exatamente igual à original (sem os campos de histórico) e ter um mecanismo que sincronize os metadados da tabela original com essa. Os dados de historico seriam guardados numa tabela à parte com uma chave apontado o item da tabela de historico. Ao ler seria feito um join das duas.
|
Criando sua própria API de Validação
Blog do MiddleHeaven |
|
|
 |
![[Post New]](/templates/default/images/icon_minipost_new.gif) 06/11/2007 09:47:15
|
bonfarj
Java Ninja
![[Avatar]](/images/avatar/1454ca2270599546dfcd2a3700e4d2f1.jpg)
Membro desde: 28/03/2006 09:55:47
Mensagens: 298
Offline
|
Valeu, Ferryman, estou dando uma olhada! Achei pouca documentação sobre ele na Internet, achei estranho isso, parece que não é um design pattern muito usado.
ATUALIZAÇÃO: Só agora vi o post do sergiotaborda, vou começar a ler agora, parece interessante.
Abraços,
This message was edited 1 time. Last update was at 06/11/2007 09:51:07
|
IGOR BRITO ALVES
@igoralves
|
|
|
 |
|
|
|
|