Estava lendo o ótimo artigo do Shoes, onde me bateu uma dúvida. Ele relata que:
“Algumas vezes, entretanto, é necessário que o Controller fique isolado desta. Este é o caso, por exemplo, quando possuímos mais de uma interface, como Swing e HTML. Neste caso, pode-se utilizar uma Camada que quase sempre está implícita, a Camada de Aplicação.”
Não entendi ao certo, a que nível de isolamento ele se referiu. Isolamento com uma classe privada a classe de apresentação (Como até então, eu conheço…), ou isolamento de classes mesmo?
Se for da segunda opção, como fazer isso funcionar de maneira elegante? (Sem aquele monte de set com objetos zumbis)
Estava lendo o ótimo artigo do Shoes, onde me bateu uma dúvida. Ele relata que:
“Algumas vezes, entretanto, é necessário que o Controller fique isolado desta. Este é o caso, por exemplo, quando possuímos mais de uma interface, como Swing e HTML. Neste caso, pode-se utilizar uma Camada que quase sempre está implícita, a Camada de Aplicação.”
Não entendi ao certo, a que nível de isolamento ele se referiu. Isolamento com uma classe privada a classe de apresentação (Como até então, eu conheço…), ou isolamento de classes mesmo?
[/quote]
Isolamento assim: Se quiser mudar de Swing para HTML e depois para SWT e de volta para AWT o controller sempre é o mesmo. O controller é independente da tecnologia de apresentação e dependente do objetivo da aplicação ( por isso ele se chama controller : controlador. O controlo é sempre o mesmo)
Imagine que eu tenho uma classe ConsultaUsuarioAction. Se estou utilizando um MVC baseado em POJOs esta classe deve ser algo parecido com:
class ConsultaUsuarioAction{
public Resposta executar(Requisicao r){
//pega parametros da requisicao, manda para um objeto de negocios
String login = r.getParametro("requisicao");
//recebe a resposta do objecto de negocios e coloca na resposta
Usuario buscado = gerenciadorUsuarios.buscarPor(login);
Resposta r = new Resposta();
r.put("usuario", buscado);
return r;
}
}
Esse cara contêm um pouco da lógica de aplicação do sistema. Eu posso utilizar num template JSP:
Seguindo as explicações do Shoes, imagine que a cada solicitação de um formulário seu para o cadastro de um cliente, vc invocaria o controller CadastrarClienteController. Se vc estivesse na Web com Struts, vc teria o CadastrarClienteAction. E se vc tivesse a mesma ação em um ambiente cliente servidor com SWT, vc deveria ter o CadastrarClienteController duplicado?!? Não!!! Vc teria um CadastrarClienteController padrão, tanto para o Struts quando para o SWT. Mas na CAMADA DE APRESENTAÇÃO, vc teria uma Action que chamaria este controller e um evento/formulario/ação (ou sei lá o que) pra tratar a mesma coisa no SWT, chamando o mesmo CadastrarClienteController.
Com isso vc teria a camada de controle (*Controller) desacoplada ta tecnologia utilizada para a apresentação (*Arcio, *Component, etc)
Pegando uma carona na dúvida de nosso amigo, pergunto:
Como então estruturar meu Controller, sabendo eu que ele deve aceitar ENTRADAS e gerar SAIDAS (Request, Response), para que ele se torne independente de visualização?
Como vocês fazem no item acima, algum exemplo/modelo/idéia?
[quote=peerless]Bom, vamos refinar minha dúvida! De exemplo, o swing.
[code]public class MyView {
private class MyControl {
}
}[/code]
Minha dúvida é: Como a MyControl é privada à MyView, ela conhece toda e qualquer mudança da apresentação, seus componentes e seus respectivos valores.
[/quote]
Já começa mal.
O controlador não é uma inner classe do view porque ele precisa ser desacoplado
A comunicação entre o controller e o view é feita por eventos e interfaces e não por código promiscuo.
public class MySwingView {
ViewController controller ; // injetar aqui o controlador correto
}
public class MyNotSwingDependantControl implements ViewController{
}
Para pertencer a, hmm, digamos à instancia da view…
minha dúvida foi, qndo tu citou algo referente a “separar” … ja me tapou o cérebro nesta situação… já imaginei, uma separação de arquivos (.java mesmo) onde teria uma View e uma Control publica…
Desculpe minha ignorancia, mas ainda estou engatinhando… abraços e parabéns pelos artigos, são referencia para toda nossa comunidade.
[quote=sergiotaborda][quote=peerless]Bom, vamos refinar minha dúvida! De exemplo, o swing.
[code]public class MyView {
private class MyControl {
}
}[/code]
Minha dúvida é: Como a MyControl é privada à MyView, ela conhece toda e qualquer mudança da apresentação, seus componentes e seus respectivos valores.
[/quote]
Já começa mal.
O controlador não é uma inner classe do view porque ele precisa ser desacoplado
A comunicação entre o controller e o view é feita por eventos e interfaces e não por código promiscuo.
[code]
public class MySwingView {
ViewController controller ; // injetar aqui o controlador correto
}
public class MyNotSwingDependantControl implements ViewController{
}
[/code][/quote]
Beleza… mas ai surge minha dúvida…
este controlador seria meu handler que trataria os eventos. Eu teria esta composição, ok… digamos:
meuButton.addKeyListener(controller);
como o meu controller iria conhecer o “meuBotao” ou a “minhaTable” ou “qualquer-outro-componente-da-view”
?
O controlador não é uma inner classe do view porque ele precisa ser desacoplado
A comunicação entre o controller e o view é feita por eventos e interfaces e não por código promiscuo.
[/quote]
Beleza… mas ai surge minha dúvida…
este controlador seria meu handler que trataria os eventos. Eu teria esta composição, ok… digamos:
meuButton.addKeyListener(controller);
[/quote]
Não se vc quer manter o seu controlador independente do view ( que é o que estamos a falar neste topico)
a classe do controlador não pode imports (dependencias) de nada da view. Logo não pode depender de listeners e afins.
A sua View Swing deve traduzir esses eventos em chamadas a métodos genéricos do controlador.
Em outras palavras: A UI Swing envia eventos para a ViewSwing que intrepreta esses comandos e comunica com um controlador generico.
Simplesmente não vai. O caminho é view --> controller e não ha retorno.
Se o controller deseja mudar alguma coisa ele deve modificar o model. O model , sim, avisa a view.
A sequencia de eventos é:
cliente -interage com -> view -notifica-> controller - modifica-> model -notifica-> view -lê-> model.
O Correto, então é que os componentes implementem os listeners dentro da view (ou em uma inner auxiliar), para então chamar o controlador, o qual teria apenas métodos de ligação com o model e de resposta a view, etc e tal?
Bom, ja vi que infelizmente, fui ensinado errado na faculdade.
Logo, teriamos, digamos, 4 camadas:
view
inner (handler listener)
controle
modelo
?
Eu normalmente associava controller a um escravo das implementacoes dos listeners, e tratamento destes eventos.
Na verdade não…
seus listeners fazem parte da camada view…
pois estes listeners estão diretamente acoplados a sua view.
Uma view web não via ter estes listeners…
Uma coisa são classes separadas, outra são camadas distintas.
[quote=nbluis]Na verdade não…
seus listeners fazem parte da camada view…
pois estes listeners estão diretamente acoplados a sua view.
Uma view web não via ter estes listeners…
Uma coisa são classes separadas, outra são camadas distintas.[/quote]
