eita nao ta dando nem tempo de eu responder, ehhe ai meu retorno fica atrasado em relação as outras respostas, :lol:
mas vamos la: entao farei o seginte: classe RevistaDAO com os SQL’S, classe Revista com os campos e set’s and get’s (memoria nos campos) e os save and updates(que chamam a DAO para gravar e recuperar do Banco) ai os tratadores de evento da view instanciam apenas a classe Revista e chama os get’s and set’s o save(). que por sua vez chama a DAO…!! certo!! 8)
Para desacoplar a Revista dos DAOs, no caso do revista.save, eu usaria herança (RevistaVolatil -> RevistaPersistente - com o método save) ou uma classe abstrata (Revista é abstrata, RevistaFísica implementa save). Essa segunda opção pressupõe que a revista em si tem natureza persistível, já a primeira extende uma revista para torná-la persistível. Acho que depende do caso, mas a segunda alternativa me atrai mais:
class Revista {
String titulo;
String edicao;
Editora editora;
Map<Materia> materias;
// Métodos de "inteligência"
public PapelPicado rasgar();
public Pagina proximaPagina();
public Fumaca queimar();
// Natureza persistível
public abstract void save();
public abstract void load();
} class RevistaQualSeriaUmBomNome extends Revista{
public void save() {
dao.save...
};
public void load() {
dao.load...
};
} Dependa de abstrações, nao de implementações.
Faça sua classe de negócio depender de uma interface com métodos save/delete/update e faça seu DAO implementar essa 
Pelo menos eu concordo 
É isso ai galera, ta muito produtiva essa nossa discussão, creio que muita gente vai se aproveitar dela!!!
pcalcado: como estou iniciando, nao entendi muito bem a sua colocação? como seria isso: minha classe de negocios depender de uma interface? ela estenderia uma interface e ficaria obrigada a implementar tais metodos? ou ela implementaria uma interface(implements)?
[quote=pcalcado]Dependa de abstrações, nao de implementações.
Faça sua classe de negócio depender de uma interface com métodos save/delete/update e faça seu DAO implementar essa
[/quote]
Tava pensando nisso. Talvez um save abstrato não fugiria muito de uma estrutura “daótica” hehehehe. No caso o que falei tornaria o bicho independente até do conceito de DAO, mas se save é persistência, que outra coisa que não um DAO eu usaria no save? Taí! gostei:
class Revista {
String titulo;
String edicao;
Editora editora;
Map<Materia> materias;
// Métodos de "inteligência"
public PapelPicado rasgar();
public Pagina proximaPagina();
public Fumaca queimar();
// Natureza persistível
public void save() {
abstractDAO.save...
};
public void load() {
abstractDAO.load...
};
} Uma dúvida Shoes: normalmente como você fornece a implementação do DAO à classe? Construtor? SetDAO? IoC?
calma la galera, ta aparecendo um monte de ideias e ja to me confundindo!!!
Renato porque abstractDAO??? como seria isto??
[quote=fredferrao]
pcalcado: como estou iniciando, nao entendi muito bem a sua colocação? como seria isso: minha classe de negocios depender de uma interface? ela estenderia uma interface e ficaria obrigada a implementar tais metodos? ou ela implementaria uma interface(implements)?[/quote]
Você tem as classes na camada de negócios, sei lá: Cliente.
A classe Cliente precisa de algo que persista seus dados, no caso era o dao.
class Cliente{
private DaoCliente meuDao = new DaoCliente();
public save(){
meuDao.save(this);
}
}Nada demais, exceto pelo fato que qualquer mudança na classe DAO, que está na camada de persistência, afeta diretamente a classe Cliente. Mau, mau, mau!
Vamos fazer o Dao implementar uma interface da classe de negocios:
class DaoCliente implements ClienteRepository{
//...
}E fazer o Cliente depender do Repository:
class Cliente{
private ClienteRepository repositorio = null;
public void setRepository(ClienteRepository rep){this.repositorio=rep;}
public save(){
repositorio.save(this);
}
}Agora seu cliente depende de uma abstração, um lugar onde clientes são armazenados. Se é um DAO, uma classe que gera HQL, um serializador, tanto faz, desde que ele cumpra o contrato.
Eu adotaria uma abordagem qualquer que não a propria classe instanciar (nesse caso a idéia não vale de nada 
).
Uma Factory funciona bem na maioria das vezes, fiz bastante isso já, e IoC para quem puder usar.
Tipo afetaria se os mudasse os nomes de metodos e argumentos certo? pois o resto esta encapsulado!!
e ficou soh uma duvida de como seria essa classe repository? ela teria apenas os metodos abstract save() e etc?
[quote=fredferrao]calma la galera, ta aparecendo um monte de ideias e ja to me confundindo!!!
Renato porque abstractDAO??? como seria isto??[/quote]
Eu só coloquei para indicar que o DAO que a Revista referencia é uma interface ou classe abstrata, não uma classe concreta. O que importa para a Revista é o DAO.save, não como ele é implementado. Por exemplo, você poderia definir uma interface RevistaDAO e criar implementações dela: RevistaDAOJDBC, RevistaDAOXML, RevistaDAOHibernate etc. No caso Revista não ia saber da existência de nenhuma implementação, apenas a interface. E a instanciação da interface, como o Shoes disse, seria feita externamente e fornecida à Revista, porque se a própria Revista instanciasse, ela ainda estaria acoplada a uma implementação.
“uma classe que gera HQL, um serializador, tanto faz”, me parece apenas um nome diferente do ponto de vista das regras de negócio para um DAO. Ou seja, no fundo ClienteRepository é um DAO sem merchandising
Boa Pergunta…
É que eu fiz isso… estou usando dao.save() no meu projeto de final de curso, e ainda assim estou apanhando que nem um cachorrinho… :mrgreen:
Bom, mas já q vcs estão dando uma aula, retire o q falei. Use a abordagem revista.save().
Olá… deixe-me fazer uma perguntinha…
isso aqui é legal na opinião de vocês?
Revista revista = new Revista();
revista.load(15); // 15 é a id da revistaEu acho isso meio feio. Vcs acham também??
Renato,
A questão é que DAO é uma implementação, a proposta é você abstrair isso, em um repositório, um lugar onde clientes (ou revistas :P) ficam armazenados.
Não é proque um objeto conhece seu DAO/Repositório, que ele tem as responsabilidades deste.
Você pdoe muito bem fazer
Cliente c = clienteRepository.load(nome);E manter o objeto Cliente só com um método save() que usa a função no respositório.
show de bola philip!
Eu já tinha engatilhada uma pergunta de como fazer querys… mas deixa pra lá… :mrgreen:
[quote=pcalcado]Renato,
A questão é que DAO é uma implementação, a proposta é você abstrair isso, em um repositório, um lugar onde clientes (ou revistas :P) ficam armazenados.[/quote]
Mas um “repositório” na prática não define uma interface estilo DAO (métodos de persistência)? Na prática o que uma interface DAO tem que uma interface ClientRepository não tem?
HUmmm… feio! Que tal:
Cliente c = Cliente.load(nome) {ClienteRepository.load...};Método estático. Acho mais coeso. Seria válido?
Humm… boa…
Mas tenho uma opinião quanto ao assunto.
E se você implementasse o método save da Revista, ex:
public class Revista {
public void save() {
Statement stmt = conn.createStatement(INSERT_SQL);
// restante do método
}
}Se meu método save possui a implementação da persistência, então minha classe de modelo também é DAO?
Eu acho que não é por que temos código de persistência que quer dizer que ele seja um DAO!
Abraços!
Thiago
Mas a idéia é tirar a implementação da persistência da classe de negócio, e não deixar junto.
sim, a idéia é tirar a implementação…!
Mas o q estou questionando é que, e se eu fizesse assim. Não é só por isso que o meu modelo passaria a ser um DAO. Ele ainda assim continuaria a ser o modelo. Ou estou errado?
Isso quer dizer que, se eu chamar o método ClienteRepository.save(this) dentro do método save da classe Revista, pode ser que ClienteRepository apesar de fazer mais ou menos a mesma coisa que um DAO faz, ele ainda assim não seja um DAO!
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=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.