Entendi o seu ponto Phillip. Mas nesse caso específico que estamos falando, não vejo muita tragédia em chamar de DAO…De qualquer forma, vou guardar seu conselho na mochila, e me lembrar dele em caso de problemas 
Valeu!
A questão não é chamar de DAO, Renato, é depender de um DAO. Você deveria depender de uma abstração… to ficando repetitivo 
Uma abstração de mais alto nível que um DAO, um DAO pode parecer um nome legal, mas é um padrão documentado e conhecido.
Chame de Repository, Database, Joaninha, sei lá, mas tenha essa abstração e não acomple ela com o DAO, faça A classe cliente e o DAO dependerem desta abstração (uma interface), não faça o cliente depender diretamente do DAO, principalmente se você está usando Active Record.
Acho que já nos entendemos sem nos entender
Bom, Renato… acho que deu para entender sim!
Veja bém…
Tudo se resumi no seguinte: Dane-se se o nome é DAO, o que importa é que vc sabe que tal classe é responsável pela persistência… Ela pode ser chama joaninha (boa)… gafanhoto… caixa de fósforo…, ou até mesmo…
SuperGuardadorDeDadosInstantâneoDeEstadoDeObjetosTabajara :mrgreen:
Outra coisa que entendi é para tu nunca deixar seu modelo depender de um dao. tipo isso aqui:
[code]
public class Aluno {
public Aluno() {
AlunoMySQLDAO dao = new AlunoMySQLDAO(); // <-- coisa feia, muito feia mesmo!
}
public void save() {
dao.save(this);
}
}[/code]
talvez fosse mais conveniente algo assim…
[code]
public class Aluno {
private PersistidorDeAluno pa;
public void setPersistidorDeAluno(PersistidorDeAluno pa) {
this.pa = pa; // <<-- que bonitinho.. :)
}
public void save() {
pa.save(this);
}
}[/code]
Desta forma, vc pode injetar um persistidor de aluno no seu modelo! Seja via IoC ou qualquer outra coisa!
Thiago, foi uma brincadeira
Depois de tanto sacrifício do Shoes, essa idéia de abstrair até o nome das paradas já tá se impregnando na minha cabeça
Olá…
Meu nome é Patricia e estou num grupo de pesquisa onde estamos trabalhando com MVC.
Eu vi o forum e achei legal para trocar informações e gostaria de aporveitar a oportunidade para perguntar se vcs poderiam me ajudar com algumas duvidas… e eu também ajudo no que eu souber…
Gostaria de saber se o main fica mesmo na camada de controle.
[quote=patty.cefetsjbv]Olá…
Meu nome é Patricia e estou num grupo de pesquisa onde estamos trabalhando com MVC.
Eu vi o forum e achei legal para trocar informações e gostaria de aporveitar a oportunidade para perguntar se vcs poderiam me ajudar com algumas duvidas… e eu também ajudo no que eu souber…
Gostaria de saber se o main fica mesmo na camada de controle.[/quote]
fóm.
[quote=renato3110][quote=Fox McCloud]Onde fica a classe Main?
O tratamento de eventos fica na View ou na Controller? Parece-me lógico que na controller, mas como?
[/quote]
No meu entendimento de MVC no desktop, o Controller é o gerenciador da View e do Model. O Controller é a sua classe Main (o “boot” da aplicação), mais os manipuladores de eventos que chamam as regras de negócio (Model).
Resumindo, a GUI gera eventos (View) que são tratados pelos manipuladores de evento (Controller), acessando de alguma forma a lógica da aplicação (Model).
Veja http://www.churchillobjects.com/c/14058.html.
[/quote]
DAO = Data Acess Object …
é um objeto que te fornece acesso ao dado(s) …
criar um dao separado é muito mais elegante, legivel a manutenção fica melhor …
ou no meu caso que eu uso um DAO generico p/ qualquer entidade do meu banco eu uso a mesma classe DAO …
se vcs forem pensar, todo dao sempre tem:
save
load
delete
update
listAll
se você cria dentro de cada bean seus métodos para acesso a bacno de dados imagina só …
quando se trabalha em sistemas com 100 tabelas, ateh menos que isso …
criar 15 beans copiando e colando os mesmo métodos:
save
load
delete
update
listAll
e trocando dentro de cada um o nome da tabela do seus selects (caso esteja usando jdbc) não é produtivo…
pensando no pattern DAO se você tem uma classe Revista e dentro dela os métodos p/ acesso ao banco eu não diria que ele é um DAO pois alem de ser o objeto q fornece os métodos de persistencia, ele tambem é um objeto que armazena o dado retornado.
Ja vi objetos serem o DAO, O lugar aonde o dado fica guardado e alem disso fornece métodos para validação dos dados …
minha opinião é de que você tem que separar tudo isso …
criando seu Bean, seu DAO e sua classe p/ validar o seu bean…
quando se separa tudo isso você conseguir enxergar melhor o sistema e
ver aonde pode generalizar.
No caso dos DAOs são todos iguais …
No caso de validação existem as validações padrões …
No caso de beans, todos se resumem a getters e setters mas não achei muitas alternativas …
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…