:lol: hehe!! Isso é meio folosófico mesmo!
Mas por que vc se preocupa em passar dados desnecessários para o dao? Se o DAO vai persistir, ele vai persistir apenas o que interessa!
A não ser que vc tenha algum tipo de DAOTraira!??? :shock: :shock:
Abraços!
Até Amahã… fui 
Foi a parte dos atributos desnecessários que não entendi.
Se você tem uma ‘engine’(ainda não encontrei) de persistência imutável, você não precisará obrigatoriamente dos DAOs.
Se ela é mutável, qual o problema do DAO conhecer a implementação do objeto que ele deve persistir? Se ele é responsável pela persistência de determinado objeto, ele tem um tipo de contrato com o objeto, não vejo o por que de não conhecer sua implementação. Afinal, quem utilizará o DAO é somente o objeto(Funcionario>FuncionarioDAO), e não um outro objeto qualquer do domínio.
Estou sendo apenas puritano.
Se fomos implementar o OO realmente devemos expor somente os atributos que necessários que fazem parte do modelo de negócios.
ex:
class Funcionario
{
// existe por necessidade da persistencia NO CASO;
private int id;
public void setId(int id) {}
public int getId() {}
// metódos e atributos de negocio, importa para o modelo
private String nome;
public void setNome(String nome) {}
public String getNome() {}
public void salvar()
{
}
}
O id no caso é um atributo que não faz parte do modelo de negócio esta aí apenas por necessidade da persistencia;
Se ele fizesse parte do modelo não teria problema.
A questão é que o DAO provalmente ficará em outro pacote o que faz com que todos os atributos da classe Funcionario que serão persistidos pelo DAO precisarão ser public;
Nao necessariamente. Atraves de reflection (e permissoes de seguranca apropriadas) voce consegue ler atributos privados de praticamente qualquer classe.
Pergunta: pq vc nao le mais sobre o Hibernate? Ele faz tudo isso que vc quer fazer, sem enchecao de saco, sem mutilar os seus objetos, sem frescura, e tem um moooooonte de outros projetos rodando com ele em producao pra provar que a coisa funciona. Pq nao?
Cv pode ser uma alternativa o reflection.
Referente ao hibernate eu tenho a plena noção de que é a mehlor solução de persistencia hoje.
O topico aqui é apenas para a discussão de uma arquitetura gernérica, ou seja, um discussão puramente “filosófica”.
É difícil eu sei, mas se algume falasse para vc como já falarm para mim:
É por isso que eu fico enchendo o saco do pessoal, para estra preparado para casos como esses…
Nao “pode ser”. É! :mrgreen:
[quote=jprogrammer]Referente ao hibernate eu tenho a plena noção de que é a mehlor solução de persistencia hoje.
O topico aqui é apenas para a discussão de uma arquitetura gernérica, ou seja, um discussão puramente “filosófica”.[/quote]
Entao pra que discutir e filosofar em cima de um problema resolvido?
[quote=jprogrammer]É difícil eu sei, mas se algume falasse para vc como já falarm para mim:
Nosso sistema roda em CACHÉ ou MUMPHS ?[/quote]
Nao, mas roda em cima de MySQL, Oracle, PostgreSQL, SQLServer, Interbase/Firebird ou praticamente qualquer outro banco de dados QUE MAIS ALGUEM NO MUNDO USE, e a gente exporta pro seu treco aí usando um script de menos de 100 linhas em Perl, Python, Groovy ou Ruby. Que tal?
Uhhh… ta 
Fim de papo.
[quote=jprogrammer]É difícil eu sei, mas se algume falasse para vc como já falarm para mim:
Se a ‘engine’(ah, desisti) de persistência foi definida como imutável, sacrifique quem definiu isso.
Se não foi, basta só mudar o datasource ou os parâmetros da classe de conexão.
Mas o que mudar o banco tem ha ver com o atributo privado lá de cima?
O problema do atributo privado é a frescura OO.
E tem fundamento.
Esse atributo id só existe para a persistencia não para o modelo no caso.
Se eu quiser deixar a aplicação o mais OO possivel tenho que esconder esse atributo.
Mas como é dificil ter uma aplicaçao 100% OO vamos deixar.
É dificil coincidir uma modelagem OO com as limitações tecnoloógicas como persistencia que não faz parte do modelo de negócio.
Como foi abordado em outro tópico temos que adaptar nossas classes para a persistencia.
EDITADO:
No caso existem formas de persistencia não relacional.
Ter DAOs que persistem nessas formas é importante se quisermos ter uma arquitetura generica.
O dilema está entre EXPOR OS DADOS DA CLASSE DE DOMINIO PARA ESSES DAOS PODERAM ACESSÁ-LOS
@heditadu
Esse seu pensamento é semelhante a uma parada que tenho refletido ultimamente. Tipo, você tem os seus objetos de negócio (domínio sei lá), que é independente de qualquer coisa, não conhece anotações, persistência, serialização XML, enfim, são independentes. No entanto, são inúteis na prática. Ou seja, você cria seu domínio (não sei se tô usando o termo certo), mas precisa torná-lo em algo palpável, em algo real, utilizável. Ou seja você traz os seus objetos do contexto abstrato pro contexto concreto, adicionando-lhes aspectos tecnológicos. Tipo vira EJB, vira Servlet (hein?), possui persistência Hibernate, depois JDBC etc, é capaz de interagir agora com Frameworkmela Talz, e tem XML no meio, e etc etc etc.
Tá mas qual é o problema? Parece-me que as pessoas se decepcionam quando embutem persistência, XML, Excel, PowerRangers etc nos objetos de negócio quando descobrem que os colocou numa cova, atrofiados de tecnologias. E se decepcionam quando tentam separar isso, quando os objetos passam a ser mais puros, mas menos inteligentes e cria-se outras classes externas para ajudar os coitados, ficando uma coisa espalhada e menos fácil de usar. Tipo um dilema.
Solução? Poder clicar no objeto com o mouse, escolher Add/Remove Aspect e escolher da lista: PersistenceAspect, SendMailASpect, RMIASpect, XMLAspect, JNIASpect, e por aí vai.
Problema dessa solução? Ela não existe.
Tá meio ou total embolado mas para os guerreiros que porventura consigam entender “meus sentimentos” (alguém??), é isso.
PS: acho que essa foi a viagem na maionese OO mais doida que ja fiz. 
[quote=jprogrammer]No caso existem formas de persistencia não relacional.
Ter DAOs que persistem nessas formas é importante se quisermos ter uma arquitetura generica.[/quote]
Me da um exemplo de um projeto em que voce esteve e, do nada, chegaram pra voce dizendo que nao iam mais usar bancos de dados, e que de agora em diante toda a persistencia de objetos seria feita atraves de palitinhos de dente cuidadosamente dispostos em forma binaria pela tia do café?
Uma arquitetura generica como essa que voce propoe (e, pelo visto, nunca pos a mao na massa pra fazer uma, ou voce saberia que se fosse tao facil ja teriam feito) nao funciona e nunca vai existir pq cada meanismo de persistencia tem peculiaridades diferentes, e objetos vivos na memoria simplesmente nao sao a mesma coisa quando transformados em uma serie de bytes, por mais macumba que voce faca.
Isso nao eh um dilema. Eu ja mostrei nessa mesma thread que isso eh perfeitamente possivel e facil de fazer usando reflection. Voce nao le os meus posts, ou nao entendeu o que eu disse?
O cv o negócio do reflection eu gostei e é a solução.
Apenas estava explicando para o Rafael Nunes o porquê da discussão com o atributo privado.
Mas estava pensando em uma coisa…
E colocar atributos no DAO.
Podem falar se fica tosco.
class Funcionario {
private String id;
private String nome;
public void setNome(String nome) {
this.nome = nome;
}
public void cadastrar() {
FuncionarioDAO funcionarioDAO = getFuncionarioDAO(); // factory
funcionarioDAO.setId(geraId());
funcionarioDAO.setNome(nome);
funcionarioDAO.salvar();
}
}
class FuncionarioDAO {
private String id;
private String nome;
public void setId(int id) {
this.id = id;
}
public void setNome(String nome) {
this.nome = nome;
}
public void salvar() {
session.save(this);
}
}
Funcionario f = new Funcionario();
f.setNome("Maria");
f.cadastrar();
Estranho esse papo de “arquitetura generica”. A minha opiniao sobre isso eh algo que tenta solucionar os problemas do mundo e acaba sempre detonando 200 bombas atomicas.
Se ficar discutindo a “filosofia” apenas, onde isso tudo ira chegar? talvez em 10 paginas de mensagens e nenhuma coisa nova agregada.
Vai chegar num ponto - e nao precisa de muito esforco para isso - onde abstrair algo vai ser estupidamente dificil, e voce acabara fazendo horrores de codigo para conseguir deixar “generico”, e, em razao disso, voce tera complexidade / bugs em demasia
Rafael
[quote=jprogrammer]
Mas estava pensando em uma coisa…
E colocar atributos no DAO.
Podem falar se fica tosco.[/quote]
HHmm… voce fez o DAO ser uma copia da entidade simplesmente para “evitar” uma possibilidade remotissima de algum codigo “malicioso” tentar acessar atributos via reflection? Nao me parece uma boa coisa.
Se voce quer tanto evitar passar um Funcionario ao save() do DAO, entao faca pelo menos o save() receber todos os parametros (save(nome, endereco, salario) ). Mas, de qq maneira, voce esta sacrificando legibilidade e facilidade de manutencao por uma hipotese que muito provavelmente nao ira afetar de maneira relevante o seu sistema.
Rafael
Na prática mesmo isso é perda de tempo.
Concordo com vc Rafael.
Apenas gostaria de discutir…
Eu acho que agrega sim.
Mas pensando bem até que não ficou ruim…
Não vejo empecilho na manutenção desta maneira.
O estranho é o nome de DAO, mas que não deixa de ser DAO.
Sei lá outro nome…
O estranho é mapear o DAO no hibernate. :lol:
[quote=jprogrammer]Na prática mesmo isso é perda de tempo.
Concordo com vc Rafael.
Apenas gostaria de discutir…
Eu acho que agrega sim.
[/quote]
Agrega ate certo ponto. Porem, bater o pe por causa de ter que ter um id ou nao, “simplesmente por causa da persistencia”, eh meio que chover no molhado.
Discutir a implementacao agrega bastante.
Rafael
[quote=jprogrammer]M
O estranho é o nome de DAO, mas que não deixa de ser DAO.
Sei lá outro nome…
[/quote]
VO? DTO?
Rafael
O pessoal chato deixa o cara bostejar, é ótimo fazer isso.
E jprogrammer, quanto a solução, eu curti o que o Shoes sugeriu em outro tópico, com interfaces internas. Jájá posto algum código.
JProgrammer!
Você pensou na possibilidade de seu objeto de domínio gerar um arquivo xml, e passar esse documento xml para o DAO!
O DAO por sua vez conheceria apenas os dados que estão no arquivo xml, e nada mais! Ele não será capaz de interagir com seu objeto de negócio de maneira alguma, garantindo desta maneira a proteção e segurança que você tanto deseja!
Isso não é lá grande coisa. Nada mais é que um DAO, mas ao invés de passar um objeto como DTO, ele passaria um Arquivo XML!
Agora se prepare:
Abraços!
Thiago Senna
Parabéns Thiago! Você acabou de criar algo parecido com um DTO, só que muito, muito pior!!! :XD: