tiago é isso que me deixando com duvida? porque ClientRepository.save(this) e nao dao.save(this)
Uma classe pode desempenhar o papel de vários patterns, porque não?
DAO - http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html
Se seu objeto se encaixa no padrão, sim, então ele também é um DAO.
Isso. Eu entendo como um DAO como uma classe especializada em persistência apenas.
na verdade meu projeto esta em casa, ainda estou pegando as ideias aqui, pra chegar la e colocar em pratica!!
mas no exemplo do philip o daoCliente implementa ClientRepository!!
isso que ta me deixando com duvidas!!
Bom… é isso que eu entendo também. Isso quer dizer que sua classe pode possuir rotinas de persistência, e mesmo assim não ser um DAO!
mas…
Entaum, agora a dúvida é a seguinte. Com o que o Daniel é disse, agora estou pensando sobre o que é encapsular e abstrair o código de persistência. Seria colocar isso em uma classe, ou pode ser em uma classe que tenha outras responsabilidades???
Vê o diagrama.
Hummm agora entendi. Isso aí o Shoes seria indicado para responder. Qual a diferença, além de nomenclatura, entre ClienteRepository e um DAO?
[quote=Thiago Senna][quote=fredferrao]pessoal li re-li e acho que estou começando a “captar” a ideia do philip.
ta entao no setRepositorio eu passaria como argumento o daoCliente, que “é um” repositorio certo???
[/quote]
Como vc criou um setRepositorio, seria mais conveniente vc passar uma classe que implemente repositorio, tipo clienteRepository, e não um daoCliente!
Isso é bobeirinha… Só dê nomes que tenham mais haver um com o outro.[/quote]
Não Thiago! O daoCliente seria uma implementação de clienteRepository, de acordo com o Shoes disse. Dá uma olhada nos posts anteriores. Fred, pelo o que entendi é isso mesmo.
[quote=danieldestro]Uma classe pode desempenhar o papel de vários patterns, porque não?
Se seu objeto se encaixa no padrão, sim, então ele também é um DAO.[/quote]
Mas acho que o que o Thiago falou não se encaixa não, porque pra mim a idéia do DAO é ser um “provider” para alguma classe separada, não para a própria classe em si:
Cliente -> lógica
ClienteDAO -> só persistência
É uma questão de entender ou interpretar o que é um DAO. Pra mim o DAO é um troço separado e que mexe só com persistência, mas não sei se é absurdo eu pensar dessa forma.
No caso essa classe com outras responsabilidades além da persistência, tipo um multi-uso hehehe, ela funcionaria como um DAO, mas não seria um DAO puro. Mas se o DAO é o próprio objeto o qual ele provê, então ele não é mais um DAO, ele é um objeto que cuida da persistência sozinho. @+ ou seja, é um objeto de lógica de negócio com persistência embutida, o que o DAO propõe-se a desacoplar. No meu entender.
hehe… eu também acho que é isso… cruel viu!
Isto é um Singleton, Proxy ou os dois?
[code]public class Configuracoes {
private static final INSTANCE = new Configuracoes();
private Configuracoes() {
}
public Configuracoes getInstance() {
return INSTANCE;
}
public String getHost() {
//atrvés de RMI, HTTP ou Socket ele pega a config
}
public String getOutraCoisa() {
//atrvés de RMI, HTTP ou Socket ele pega a config
}
}[/code]
ClientRepository é a interface. O DAO é uma implementação da interface ClientRepository.
Se você define bem o contrato (métodos) de ClientRepository, você não vai precisar mexer nele e pode mexer à vontade no DAO.
ClientRepository é só um nome diferente para uma interface estilo DAO.
Cara… voces deram uma volta!
É o que o destro falou, o DAO é uma implementação de uma interface. É uma abstração. Faça sua classe depender de abstrações, não de implementações.
Fred, você pegou o espírito da coisa. Para Cliente, não existem DAOs, existem repositorios, e ela recebe um. Se é um DAO implementando um repositório não é problema dela, desde que ele obedeça o contrato da Interface 
Consultas feitas diretamnete ao objeto? Pode até ser, mas eu acho isso artificial demais. Não é o tipo de cosia que se tem no mundo físico,a cho que já temos problemas demais em protar abstrações pra um modelo de software e não rpecisamos criar mais coisas sintéticas.
Colcoar uma prepared statement no seu objeto de negócios não faz um DAO, faz uma bela bagunça misturando SQL e código de persistência com regras de negócio, e até a última vez que eu lembre isso é exatamente o que tentamos evitar com DAOs e camadas.
Esse é o meu ponto. A interface Repositorio define a mesma coisa que um DAO define, então é só um nome diferente para um DAO. Do contrário, repetindo minha pergunta: qual a diferença entre uma interface DAO e uma interface Repositorio, além de não dar créditos à sigla “DAO”? Não tô enxergando diferença. ClienteRepository é uma interface estilo DAO, portanto qualquer coisa que a implemente será um DAO. Entendeu a questão Phillip?
Pense na abstração.
Mas uma interface DAO abstrai exatamente da mesma forma. A diferença é que eu a chamo de DAO. Só isso. É disso que vocÊs estão falando né? É isso? Se é, então isso é uma abstração apenas de um nome. Cliente conhece o seu Repositorio, mas nunca ouviu falar sobre DAO. Mas também não sabe que DAO é só outro nome para o seu Repositorio.
Se estamos de acordo, a questão é simplesmente a escolha do nome. ClienteDAO, para os que sabem o que é DAO, dá uma maior clareza para entender a função da classe. Já Repository seria um nome mais limpinho, abstraído.
Ufa! :roll:
Exception in thread "Como organizar um projeto Java (com UML ou não) em MVC com NetBeans?": misunderstanding.
[quote=noelrocha]chamar de Repositorio ou DAO p/ mim não faz diferença … a diferença eh que o pattern tem o nome de DAO, se vc não quer saber qual é o pattern e quer um nome que tenha mais sentido Repositorio é a alternativa…
[/quote]
Isso. Repository não é uma abstração do ponto de vista funcional como um List e ArrayList, por exemplo, mas do ponto de vista simplesmente de nome. É isso que tô tentando dizer.
Renato,
Eu costumo incluir em DAOs JDBC o seguinte:
class XyzDao{
public XyzDao(Connection conn){this.conn=conn}
public XyzDao(){}
//...
}Por que? Porque quando tenho uma caeia de DAOs chamando DAOs não quero usar todas as conexões disponíveis no pool.
Isso é um detalhe de implementação. O cliente do DAO precisa saber disso? NÃo! Isso é abstrair: se livrar de detalhes inuteis no contexto.
Então faço meu repositório (você pdoeria chamar de deposito, bananeira, jabuticaba, qualquer coisa que te faça sentido, ou melhor ainda: faça sentido no domínio) que tem as funções que o objeto de negocios precisa. Pronto.
Todo DAO oferece acesso a dados mas nem tudo que oferece acesso a dados é DAO. Active Record não é DAO. SQL msiturado no objetod e negócios não é DAO.
Como você sabe qual objeto montar? Quais os atributos correspondem a quais colunas de quais tabelas (uma classe pdoe ser mapeada em menos de ou mais de uma tabela)? Como fazer consultas específicas? O que este seu DAO retorna?
Não. Como disse acima acessar SGBD não faz de uma classe um DAO, do contrário tudo relativo a JDBC seria DAO.
Dê uma relida no padrão:
http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html
Por favor leia este topico:
http://www.guj.com.br/posts/list/21687.java
Separar responsabildiades de um objeto, dados de um lado, validação de outro, regras de outro, é quase semrpe praticar desenvolvimento segundo o apradigma procedural. Se seus beans só possuem get e set, você deve refatorar seu projeto para que a lógica de negócio fiqwue onde ela deve estar: nos objetos de dominio.
Não faz diferença porque você não captou a abstração e sua necessidade