tfNome.setText(Cliente.getNome()) ;
isso seria um modelo atualizar a view? hehehe
tfNome.setText(Cliente.getNome()) ;
isso seria um modelo atualizar a view? hehehe
O modelo responde ao controlador e o mesmo responde a view…
No caso sua view é que vai colocar os devidos valores nos campos…
Não são Camadas, são simplesmente componentes do MVC. MVC não é sobre Camadas.
Claro!
Bom, o Controller tem que receber informações, por exemplo, para apagar uma pessoa, precisa saber qual pessoa receber. Após a remoção, precisa notificar a View de que a pessoa em questão foi apagada com sucesso, ou apresentar uma justificativa do erro.
Nesse sentido, pensando em não ter nenhuma dependência à View, como vocês procedem nessa comunicação entre camadas? De forma à Controller receber as informações que precisa e retornar os dados?
Ex:
class ControllerPessoa {
public void apagarPessoa(Request req, Response res) {
//
Pessoa p = (Pessoa)req.getAttribute("pessoa");
//..acessa o modelo e apaga a pessoa
res.setAttribute(RETORNO, "OK");
}
}
ou algo mais simples:
[code]
class ControllerPessoa {
public String apagarPessoa(Pessoa p) {
//..acessa o modelo e apaga a pessoa
return("OK");
}
}[/code]
A pergunta é, como vocês fazem? (Se não for pedir demais, um exemplinho simples :))
Será que me fiz entender? Posso estar confundindo coisas…
Obrigado desde já,
Saudações
Oi peron;
Isso vai depender muito do cenário.
Depende de coisas como arquitetura, convenção e até mesmo framework que vc utiliza (se utiliza) para ligar esses componentes.
Olá!
Pode usar o xwork para ter somente uma classe Action para web e swing.
Na web vcs já sabem com funciona… é só olhar o webwork.
No swing, uma ação da interface (botão por exemplo) chama uma
Action do xwork. Este faz o que tem que fazer e coloca valores
que a view precisa no ActionContext.
Retorna o result (SUCCESS por exemplo) que então dispara um tipo
de Result. Este Result em si é específico da view, por exemplo
um pra swing seria o OpenPanelResult que abre um JPanel.
Bom, fiz aqui uma aplicação de exemplo no netbeans. Gostaria que, os interessados, dessem uma olhadinha no código, e baseado nisso, pudessem redefinir, dentro da crença correta e postar ai para galera se basear.
eu sei que não é o certo, mas a nomenclatura dos pacotes seguiu mvc… desculpem!
‘‘Refatorem’’ este exemplo, da forma que bem entender. Deste nomenclaturas, etc.
Muito obrigado, novamente. abraços!!
Se você está numa arquitetura web provavelmente vai utilizar o tal MVC2, que não é MVC de verdade. Neste cenário você em pacota o que for passar para a view na resposta como no meu primeiro exemplo ou mantêm os objetos do modelo em algum lugar que a view acesse, comoe scopo de sessão.
Se não estiver preso à web e ao pseudo-MVC MVC2 pode fazer como o Sérgio falou: a cada alteração no model a view é notificada e se atualiza. A forma de fazer isso depende da sua implementação, de qualquer forma dê uma olhada no padrão Observer.
Só uma coisa, lembre-se sempre:
[quote=pcalcado]Não são Camadas, são simplesmente componentes do MVC. MVC não é sobre Camadas.
http://fragmental.com.br/wiki/index.php/MVC_e_Camadas
[/quote]
[quote=peerless]Bom, o problema é que estou em fase de transição deste tipo de arquitetura. Ouvi muito assunto errado sobre isso. Afirmações falsas.
Continuando na idéia do Swing…
Eu não consigo pensar numa situação do model atualizando a view… como um negocio atualizaria um JFrame por exemplo??
[/quote]
não pense num JFrame, pense num JTable e seu TableModel
(JFrame é um container, não tem dados associados(normalmente))
Não. O view faria algo como
tfNome.setText(model.getValueFor("nome"));
//ou
tfNome.setText(model.getNome());
o model varia algo como
public String getNome(){
return cliente.getNome();
}
[quote=sergiotaborda][quote=peerless]Bom, o problema é que estou em fase de transição deste tipo de arquitetura. Ouvi muito assunto errado sobre isso. Afirmações falsas.
Continuando na idéia do Swing…
Eu não consigo pensar numa situação do model atualizando a view… como um negocio atualizaria um JFrame por exemplo??
[/quote]
não pense num JFrame, pense num JTable e seu TableModel
(JFrame é um container, não tem dados associados(normalmente))
Não. O view faria algo como
tfNome.setText(model.getValueFor("nome"));
//ou
tfNome.setText(model.getNome());
o model varia algo como
[code]
public String getNome(){
return cliente.getNome();
}
[/code][/quote]
Beleza sergio, tá começando a clarear.
Tu poderia baixar meu exemplo, postado logo acima, e avaliar? Valeu!
O principal problema está neste pedaço.
A view não sabe o que significa “setar” nem "remover"
O que ela sabe é que "quando o botão btnSet for apertado avisa o controlador desse fato"
Quem sabe o que fazer é o controller.
Depois tem o principio “peça, não pergunte” (Aks, don’t tell)
Aquele for deveria estar dentro do controlador porque é uma modificação do modelo e não no view( muito menos no view handler).
Eis uma ideia de como seria
class .... implements View{
public String getNome(){
return txt.getText();
}
public void updateFromModel(Model m){
txt.setText(m.getNome());
}
private class ViewHandler extends MouseAdapter {
private Controlador controle = new Controlador();
public void mouseClicked(MouseEvent e) {
if (e.getSource() == btnSet) {
controler.setNewValues(view); // isto é um evento. Poderia usar o padrão observer
}
else if (e.getSource() == btnRemove) {
controler.removeValues(view); // isto é um evento. Poderia usar o padrão observer
}
}
}
class Controller{
Model m = new Model(); // inicia so uma vez
setNewValues(View view){
m.setNome(view.getNome());
atualizarLista(view);
}
void atualizarLista(View view) {
view.updateFromModel(); // cuidado com loop infinito
}
Este boneco http://pt.wikipedia.org/wiki/Imagem:ModelViewControllerDiagram.svg
é tudo(!) o que precisa entender de MVC. As linhas tracejadas significam “envia evento” e as cheias “lê”
Controller, View e Model antes de tudo têm que ser interfaces que falam umas com as outras.
Depois vc implementa cada interface com a tecnologia que mais for apropriada. Como as interfaces garatem independencia , vc pode intercambiar uma das partes sem ter que alterar a outra.