MVC e transição de janelas

Programação Arquitetura
#1

Estou iniciando um projeto da camada de apresentação de um software!
Estou afim de usar MVC dentro desta camada!
Só que me surgiu uma dúvida.
Quem controla a transição entre as janelas?

Se alguém quiser opinar me ajudaria muito!

[]s

#2

Bruno, sem querer ser chato, mas transição de quê entre janelas?

Abraços,

#3

Transição de uma janela para outra.(Sequência de apresentação de janelas)

[]s

#4

Bom, se eh pra dar opiniao… :smiley:

Se voce vai desenvolver usando MVC parece natural que seja o Controller que gerencie isso. As Views (telas) apresentam os dados, os Models (negocio) representam os dados e o (ou os) Controller fazem o meio-de-campo, que poderia incluir o controle do fluxo da aplicacao (qual tela vai pra onde).

Marcio Kuchma

#5

Bom, se eh pra dar opiniao… :smiley:

Se voce vai desenvolver usando MVC parece natural que seja o Controller que gerencie isso. As Views (telas) apresentam os dados, os Models (negocio) representam os dados e o (ou os) Controller fazem o meio-de-campo, que poderia incluir o controle do fluxo da aplicacao (qual tela vai pra onde).

Marcio Kuchma[/quote]

Antes de tudo obrigado por opinar… :smiley:

Mas assim eu não estaria gerando uma certa dependência entre view e controle?

Eu também pensei em colocar as transições no controler porém me surgiram algumas dúvidas:

1- Se eu mudar a view grafica por uma uma view de linha de comando será que as transições continuarão sendo executadas da mesma forma? como eu generalizaria o controle de transição de views para eu poder trocar de view sem trocar o controle junto… Se tiver que trocar os dois juntos é um proble digno de refatoração dale “rifle”;

2- Se eu tenho duas views totalmente iguais em termo de funcionalidade a única coisa que muda é a transição de janelas “As ordens que eu posso abrir as janelas são diferentes”. Eu teria realmente a necessidade de criar dois controles?

Hoje eu estou me perguntando por que não colocar o gerenciamento de transição de janela na propria view alem do mais cada view pode ter uma transição diferente.

Derrepente seria uma boa criar um mecanismo proprio para gerenciar somente trancição entre janelas.

[]s

#6

É normal a view e o controller estarem fortemente acoplados.

O trabalho do controller é lidar com os comandos do usuário. Views muito diferentes (como GUI e CLI) podem ter controlles diferentes.

Você poderia usar controllers compostos para poder substituir somente uma ação específica (no caso, a transição entre janelas).

#7

O trabalho do controle não é:

  1. Receber uma ação;
  2. Extrair os dados da view para que a ação seja efetuada no controle;
  3. Validar os dados extraidos da view;
  4. Executar a ação no modelo.

Sera que as responsabilidades não são essas?

Porque se definimos legal as responsábilidade dele podemos fazer algo generico.

Alguém sabe onde eu encontro as especificações das responsábilidades do MVC, que não seja dizer a view tem a responsabilidade de apresentar os dados, o controle tem a responsabilidade de controlar a view e o model tem a responsábilidade de fornecer uma indireção para a aplicação.

Todos os autores que eu li dão essas resposábilidades vagas como em:

Padrões de aplicações corporativas FOWLER
UML e Padrões LARMAN
Aprenda OO em 21 dias SINTES

Ainda não tive a oportunidade de ver no POSA que é o livro que o FOWLER recomenda como referencia para MVC, se alguem puder me passar o que ele diz lá.

Espero que vcs opinem…

[]s

#8

A idéia de MVC é anterior às descrições de padrões em software no estilo GoF/POSA. A primeira publicação foi um artigo do pessoal do Xerox Parc no JOOP de 1988. Lá, eles descrevem um controller como:

Outra descrição útil é do Ralph Johson no wiki original:

(depois ele segue falando sobre como o Presentation Abstraction Control incorpora o MVC e as implementações nos ambientes de Smalltalk.)

Não tenho os POSA, mas se eu conseguir lembrar, dou uma olhada no texto do POSA1 na próxima vez que passar na biblioteca da facul e reposto aqui.

#9

Fowler e Larman utilizam essa visão que o controlador é uma estratégia da view.

Muito bacana esta descrição porem não consegui entender o que ele quis passar aqui:

Controllers also deal with scheduling interactions with other View-Controller paris: they track mouse movement between application views and implemetn messages for mouse button activity and input from the input sensor.

Ele esta dizendo que controladores tratam tambem de interações entre views-controles, como por exemplo utilizar dados de outra view ou estartar algo em outra view ou até mesmo controlar transições de janelas? :smiley:

Ae AllMighty obrigado mesmo pela força que vc tem me dado te devo essa…

#10