[quote=Rubem Azenha][quote=sergiotaborda]
é uma pena que vc só tenha entendendo isso porque isso nem está no texto. E eu nunca disse isso.
Vc pode usar DAO à vontade. MAs DAO verdadeiro, não esse hibrido metamorfoseado que o pessoal chama de DAO, mas que na realidade é uma camada para chamar o hibernate.
[/quote]
Eu realmente espero que ao falar que DAO é uma camada para chamar o Hibernate você apenas dado um exemplo e não falado que DAO serve só para Hibernate…
[/quote]
O problema é o seguinte: existe um conceito de DAO e existem dois usos desse conceito. Duas formas de implementar/usar. Uma é boa prática, a outra não. A boa prática é aquela relacionada ao desacoplamento do seu programa do acesso aos dados. Essa é a forma antiga, desenhada pelos EE patterns. A forma ruim é aquela em que o DAO é uma desculpa para encapsular o hibernate ou o EntityManager. É esta segunda forma a que referi como hibrido. A pessoa pensa que está seguindo a boa prática, mas na realdiade não está porque um sistema DAO com hibernate não é independente do hibernate ( por exemplo, vc tem usar o padrão session in view) , logo, isso viola a permissa original do padrão DAO que é poder trocar de implementação sem trocar nada mais na aplicação ( por isso que o DAO é definido como uma interface). Ora, quem usar hibernate/JPa não pensa em trocar de implementação. Aliás, isso nem é possivel. JPA e Hibernate são implementações de DomainStore que é um padrão inerentemente orientado a dominio. O modelo do dominio é explicito e impregnado em todos os usos do hibernate/JPA ( seja com anotações ou xml, não importa. )Vc tem que ensinar ao Hibernate/JPA o seu dominio. Com o DAO original vc não tem que ensinar nada, porque não ha dominio , existem apenas dados.
O outro lado da historia é a confusão entre DAO e Repositorio. Os conceitos podem parecer semelhantes à primeira vista, mas não são sequer da mesma familia. DAO é um serviço de infraestrutura ( usa a dobradinha interface+implementação e é independente do dominio) Repositorio é um agente do dominio ( não é definido por interface+implmentação e é dependente do dominio )
São coisas bem diferentes. Relutar em ver a diferença se escondendo na semelhança aparente é um erro. Persistir nesse erro é uma doença: o Sindrome de DAO.
A diferença entre um sistema orientado ao domínio e um sistema orientado a dados ainda não está bem clara por que, pelo que você mostrou, esses dois conceitos foram inventados por você mesmo.
[/quote]
Em um sistema orientado a dados, os dados são mais importantes que o comportamento. Vc modela dados. Vc guarda dados. Vc se preocupa com o ciclo de vida de dados. E principalmente os dados são burros ( desprovidos de inteligência de negocio). As regras de negocio são colocadas em outros lugares e espalhadas pelas diferentes camadas. As responsabilidades são mal definidas e é confuso entender quem faz o quê.
Em um sistema orientado a dominio o dominio é o mais importante e o resto é apenas uma forma de acessar o dominio ou dar suporte à existencia do dominio. Aqui o mais importante são os serviços que atuam sobre os dados e dos dados são encapsulados em objetos com inteligencia ( aka comportamento) . Padrões como strategy e template method são possiveis. Vc ainda guarda dados, mas esses dados são extraidos do dominio (são apenas os estado dos objetos) Vc se preocupa com o ciclo de vida dos serviços e não dos dados. As regras de negocio está em lugar apenas e não ha confusão da responsabilidade de cada camada.
Não tem nada a haver com os padrões. Tem a haver com a postura. Com as diretrizes que regem as suas escolhas.
Vc pode fazer um sistema orientado a dominio com EJB ( como eu tento explicar no texto) ou usando DAO e Transaction Scripts.
Ou vc pode fazer um sistema orientado a dados como repositorios , façades e SOA. É tudo uma questão de ao quê vc dá importância. Se os seus VO são burros não significa que não esteja orientando o seu sistema ao dominio, pode acontecer que simplesmente não ha nenhuma inteligencia a ser acoplada a esses dados. Agora, escolher não acoplar inteligencia, nunca, mesmo quando precisa, isso sim é sinal de o sistema é orientado a dados. O exemplo clássico é ter um método estático na classe A para fazer algo que podia ser um método publico da classe B.
[quote=sergiotaborda]
Agora, poste alguns exemplos de código de repositórios seus, vamos ver se é muito diferente dos DAOs interfaceando repository [/quote]
Eu uso uma arquitetura de Repositorio com DomainStore. O repositorio escreve critérios de procura e delega ao DomainStore.
um exemplo seria
public final class RepositorioDocumento extends
StandardEntityRepository<Documento> {
public RepositorioDocumento() {
super(Documento.class);
}
public Query<Documento> encontraPorPasta(Pasta pasta) {
return this.getStorage().query(
CriteriaBuilder.search(Documento.class).and("pasta").is(pasta)
.orderBy("nome").desc()
.all());
}
public Query<Documento> encontraPorReferencia(String referencia) {
return this.getStorage().query(
CriteriaBuilder.search(Documento.class).and("referencia").eq(referencia)
.orderBy("nome").desc()
.all());
}
public Query<Documento> encontraPorProjeto(Projeto projeto) {
return this.getStorage().query(
CriteriaBuilder.search(Documento.class).and("projeto").is(projeto)
.orderBy("nome").desc()
.all());
}
}