[quote=LIPE][quote=kuchma]…MAS na hora de puxar os dados da fonte tem essa encrenca. Nao posso utilizar Hibernate.
[/quote]
Hibernate não precisa de getters e setters.[/quote]
Exato. Se eu pudesse utiliza-lo, o problema estaria resolvido. CQD. :mrgreen:
Marcio Kuchma
Ah, confundi causa com consequencia no seu post 
Adorei essa estratégia bem interessante.
A instaciação pode ser via factory ?
Mas e o problema dos campos privados, como o mecanismo de persistencia vai exergar os atributos privados ?
Seria interessante que cada tipo de mecanismo estivesse pacotes diferentes.
[quote=jprogrammer]Adorei essa estratégia bem interessante.
A instaciação pode ser via factory ?[/quote]
Sim. Essa eh a funcao dela.
[quote=jprogrammer]Mas e o problema dos campos privados, como o mecanismo de persistencia vai exergar os atributos privados ?
Seria interessante que cada tipo de mecanismo estivesse pacotes diferentes.[/quote]
Sem colocar gets/sets publicos ou utilizar estrategias heterodoxas com reflection nao vejo solucao. Alguem? :roll:
Marcio Kuchma
Injeta via IoC
E quanto aos campos private, usa Hibernate ou faz alguma coisa nojentinha com reflection ou alguma coisa assustadora com CGLib ou BCel ou faz como o cara sugere aqui:
E se o mecanismo de persistencia extendesse de uma classe abstrata do mesmo pacote da classe persisitida ao invés de uma interface.
E nessa classe tivesse métodos acessores para a classe a ser persistida.
ex:
package teste.funcionario;
class FuncionarioPersistStrategy
{
protected abstract void save(Funcionario f);
protected void setId(Funcionario f, int id)
{
f.setId(id);
}
}
class Funcionario
{
private int id ;
void setId(int id) {}
}
Para mim parece melhor do que o normal mas não entendo por que não usar Hibernate @.@
É pro caso de não usar.
Devemos estar preparados para tudo, não é por isso que não usaria.
Ninguém é louco.
Esse é ponto que sempre coloco.
Entendo isso perfeitamente. Nesse caso eu aplicaria a mesma solução que o Hibernate, alterando o bytecode em runtime, o que não é tão complicado assim. Mas já que está prontinho pra usar …
Alguém pode se perguntar: para que essa merda toda? Posso colocar os getters e setters só para a camada de persistência funcionar e não chamá-los nunca.
Mas aí não fica bonitão né?
Deixe-me ver se eu entendi. Isso quer dizer que seu eu criar a seguinte classe abaixo, ela é perfeitamente válida para ser persistida com o Hibernate?
public class Cat {
private int id;
private String nome;
private sex;
}Será que estou confundindo Hibernate com Spring? Spring precisa de pelo menos um contrutor default né? Mas ele também depende dos gets e sets?
Perdoem-me pela confusão!
Abraços!
Thiago
Caramba !!!
O Hibernate muda o bytecode da classe ?
Eu pensei que ele fazia isso via reflection.
Isso não seria uma gambi.
Esse hibernate é do cara…
[quote=jprogrammer]Caramba !!!
O Hibernate muda o bytecode da classe ?
Eu pensei que ele fazia isso via reflection.
Isso não seria uma gambi.
Esse hibernate é do cara…
[/quote]
Aproveitando o embalo!
Por acaso é a biblioteca CGLIB quem faz com que esse tipo de gambi seja possível?
Observação:
Comecei um relacionamento amoroso com o Hibernate. Por isso vou começar a encher o saco! 
Abraços!
Thiago
Leiam aqui:
http://wrschneider.blogspot.com/2005/01/avoiding-anemic-domain-models-with.html
E com CGLib dá para fazer isso e muito mais cuidado @.@
Vou investigar isso pra ver o grau de complexidade. Se nao for limitado pelo mecanismo de seguranca da VM pode ser otimo.
[quote=LIPE]Alguém pode se perguntar: para que essa merda toda? Posso colocar os getters e setters só para a camada de persistência funcionar e não chamá-los nunca.
Mas aí não fica bonitão né?[/quote]
Exatamente. Sem contar que eh deprimente aquele monte de gets/sets no Outline do Eclipse. Polui muito o visual. :XD:
Sobre o Hibernate, como voces ja falaram, ele nao resolve todos os problemas (persistencia nao-SGBD, p.ex.). Ah, e nao precisamos de recomendacao de outro mecanismo de persistencia. Apenas de como resolver esse problema de falta de elegancia no modelo.
Marcio Kuchma
Uma outra coisa boba que estive pensando hoje de manha a caminho do trabalho…
E se as implementacoes de persistencia devolvessem um Map, que a classe de modelo utilizasse para se auto-popular? Seria uma especie de “contrato” entre as partes: o modelo apenas aceita uma entrada tipo Map enquanto que todas as implementacoes de persistencia devolvem como produto final o Map citado. Isso para carregar os dados. Para salvar, processo inverso.
MAS, com isso perde-se a verificacao de tipos. Sem contar os trocentos efeitos colaterais nao-previstos na minha sonolencia matutina - aguardo as criticas.
Enquanto isso vamos olhar a CGLib…
Marcio Kuchma
Muito tenso isso cara, ainda mais com objetos aninhados. Sei que há o commons-beanUtils, mas … dor hehe prefiro colocar os métodos mais próximos à classe.
Para usar esse negócio doido de CgLib é melhor usar HashMap.
Já pensei nisso o problema é com o hibernate.
Como vou persistir com o hibernate usando HashMap.
A tipagem talvez não seria o probelma, pois isso fica interno.
Alguém sabe ?
Hibernate suporta isso, leia a documentação do 3.0. Na verdade você pode mapear os dados para qualquer coisa que bem entender hehe
Aí não vira uma gambi medonha.
O ideal é o hibernate persistir a classe em si, não o hashmap.
Já que o phillip deu a ideia de criar um factory dos domains model objects, por que não criar várias implementações.
Um para cada persistencia.
Seria tosco isso ?
Usar um map para isso seria um desastre, com direito performance deprimente e manutenção infernal.
A questão é que java não possui um mecanismo claro de persistencia na linguagem, e isso exige que toda e qualquer solução tenha um pouco de “gambiarra” ou seja complexa o suficiente para não valer a pena.
Sinceramente, hibernate/EJB3.0/ORMxyz usando atributos privados me parece o mais próximo do ideal que pode se conseguir com java.
Isso falando de persistencia relacional, claro.