Camada Controller , como eu faço?

9 respostas
U

1)Pessoal numa estrutura MVC a tela(view) não comunicar-se diretamente com as regras de negocio(model) e sim passar antes por um controlador(controller), isso ta certo ?

  1. O Controlador tem que saber que regra chamar apartir do evento gerado na view o que view chamar apartir do evento gerado no model ?

3)pergunta tipo a view e o model não fica muito acoplado ao controller ?

4)como eu posso fazer um controller razoavel em uma aplicação swing?

ufa, qualquer resposta sera bem vinda.

9 Respostas

Luca

Olá

Sim. Entenda o modelo como V <–> C <–> M e M não fala com V sem ajuda de C. Não misture o que aprendeu de MVC com Swing e o modelo MVC2 de aplicações web.

Não entendi, o controlador é apenas um intermediário, um leva e trás, o carteiro. E o carteiro não precisa saber nada além do endereço e de como transportar as mensagens. O controlador não sabe NADA sobre eventos da view ou sobre eventos do model.

Não, a menos que se programe deste jeito.

Usando servlet no controlador

[]s
Luca

U
  1. ok, duvida sanada.

[quote]
ualex escreveu:
2) O Controlador tem que saber que regra chamar apartir do evento gerado na view o que view chamar apartir do evento gerado no model ?

Luca escreveu

por exemplo tem um item do menu Cadastrar Cliente quando o usuario clicar dispara um (ActionEvent) que sera tratado pelo controlador, né(?)
mas o controlador tem que saber quem gerou o evento para executar a regra de nogocio correta … como eu poderia fazer isso em uma aplicação desktop. tipo eu teria que fazer um mapeamento dae que eu acho que cria um acoplamento forte.

[quote]
ex escreveu:
4)como eu posso fazer um controller razoavel em uma aplicação swing?
Luca escreveu:

Mas tipo minha aplicação é swing estilo “Delphi” como eu posso usar uma servlet como controladora ?

Luca

Olá

[color=“red”]NUNCA[/color]. A view trata do que é de view. Releia o que respondi no item 2. O controlador não recebe eventos swing, recebe mensagens tipo post ou get contendo o que vc precisa passar para o model (e vice-versa). Exemplo: Em uma tela de login vc passa nome e senha. Recebe de volta OK ou não OK.

Sua aplicação é em Java e servlet é Java, esqueça Delphi, VB, Cobol, etc. Veja http://www.guj.com.br/forum/viewtopic.php?t=16091

[]s
Luca

urubatan

você pode utilizar MVC com SWING também, sem problema nenhum,

tente desacoplar os eventos swing do controller, faça a propria tela receber os eventos, e chamar o controller, passando os parametros corretos para ele.

uma boa dica é utilizar um XWork da vida, que é uma implementação de command pattern, utilizada pelo webwork para a camada MVC, mas que pode ser utilizada independente do ambiente WEB.

você pode dar uma olhada nos seguintes links (não cheguei a ler com muita atenção, mas falam da utilização do XWork para aplicações SWING :D)
http://www.magpiebrain.com/archives/000181.html
https://swingwork.dev.java.net/

urubatan

ahh, e se você é alguma espécie de early adopter,
pode dar uma olhada também no Spring Rich Client Platform
http://www.springframework.org/spring-rcp.html

Luca

Olá

Urubatan, seu post foi muito interessante pois chama a atenção que se pode usar frameworks mesmo com Swing. Eu particularmente acredito muito nisto porque unifica o desenvolvimento no lado servidor permitindo acessar o model com vários tipos de clientes.

PS: Desculpe mas acoplar evento Swing no controller não existe e nem pode existir. Se alguém um dia já fez isto seria talvez uma das maiores burradas que já teria visto nos meus 35 anos de informática. Já imaginou como seria engraçado vendo alguém serializando um descendente de um JFrame e passando para o controller só para verificar usuário e senha de uma tela de login? Seria bem pior do que colocar componente de navegação em banco de dados na tela do cliente como se fazia no início da última década do milênio passado com Delphi ou Clipper.

[]s
Luca

urubatan

“Luca”:

PS: Desculpe mas acoplar evento Swing no controller não existe e nem pode existir. Se alguém um dia já fez isto seria talvez uma das maiores burradas que já teria visto nos meus 35 anos de informática. Já imaginou como seria engraçado vendo alguém serializando um descendente de um JFrame e passando para o controller só para verificar usuário e senha de uma tela de login? Seria bem pior do que colocar componente de navegação em banco de dados na tela do cliente como se fazia no início da última década do milênio passado com Delphi ou Clipper.

[]s
Luca


valeus,
eu concordo que é péssima ideia, mas não acho que seja um crime tão grande assim,
acho que é um crime, mas de gravidade igual ou até inferior, a acoplar o controller a camada WEB como é feito em praticamente todos os freamworks MVC para web (acho que só o Web Work resolveiu isto, todos os outros passam no minimo o HttpServletRequest para o controller, e até para o model as vezes.

mas não acho que nenhuma das duas coisas seja uma boa ideia.

só para lembrar, o MVC não nasceu para sistemas WEB, nasceu a anos atraz no tempo em que nem se falava em web ainda, para o desenvolvimento de aplicações C++ e Small Talk como a maioria dos design patterns, então, todos eles podem ser utilizados em aplicações desktop e ou web.
nenhum dos design patterns (exceto alguns dos Core J2EE patterns) te obrigam a implementar a aplicação em mais de uma camada fisica, isto é, podem ser utilizados em aplicações standalone.

sei que boa parte do pessoal do forum ja sabe isto, mas é sempre bom dar uma lembrada na origem dos conceitos que utilizamos todos os dias :smiley:

Luca

Olá

Passar o HttpServletRequest de um lado para outro DENTRO do controller não é tão ruim em termos de arquitetura, apenas em termos de performance. Aliás aconselho o livro How Tomcat Works para aqueles que quiserem ter uma idéia do peso de um request ou response.

Passar o HttpServletRequest para o Model realmente é feio mas pode ser evitado. Porém frameworks como o Struts as vezes confundem um pouco sobre quem é realmente controller e quem é realmente model. E ainda estimula ficar passando estes monstros a toa.

Passar evento swing para ser tratado pelo Model, bem aí seria MUITO pior tanto em termos de arquitetura como em performance.

Sem polemizar mas já polemizando…só para lembrar o MVC que surgiu lá com o Smalltalk não deve ser lembrado na hora de escrever aplicações web. Aqui o certo é falar em VCM ou mais radicalmente ainda V-C-M para ficar claro que C é apenas um intermediário. Aqui a comunicação é linear ao contrário do MVC do Smalltalk onde M fala com V e a comunicação é circular naquele velho desenho do triãngulo.

[]s
Luca

pedromuyala

Mais conteúdo sobre MVC recomendo acessar este link: http://www.guj.com.br/posts/list/129277.java
Vou adicionar este tópico como referência na lista de links sobre MVC que estão na primeira postagem do link que estou recomendando.
Espero ter colaborado! :wink:

Criado 27 de setembro de 2004
Ultima resposta 20 de out. de 2009
Respostas 9
Participantes 4