Sim. A visão precisa do modelo para exibir os dados na tela (imagine, por exemplo, que o modelo represente um produto; na tela de modificar produtos - que é uma visão - é preciso ter acesso às informações deste produto).
Atualizar o modelo em resposta a ações na visão.
Exemplo prático: o usuário altera um dado sobre um produto e pressiona o botão OK (tudo isso na visão). O controlador é notificado e atualiza o modelo com os novos dados.
Opcionalmente, determinar qual nova visão deve ser mostrada.
Exemplo prático: ainda no caso da atualização do produto, se o produto foi atualizado corretamente, mostra uma informação dizendo isso. Caso haja algum problema, notifica o usuário.
[quote=valmorpe]
Já pesquisei muito aqui no fórum e realmente vi muitos feras dizerem que o Swing usa MVC, e neste artigo isso fica bem claro, um componente com os componente gráficos para receber o valor, para aumentar e decrementar esse mesmo valor, ou seja:
Visão é o próprio componente gráfico e o Modelo é atualizado (pelo Controlador) de acordo com a seta clicada na componente gráfico (aumenta ou decrementa o valor no Modelo). [/quote]
Sim. Swing usa MVC em diversos casos. Exemplos são JLists e JTables.
joyle, li o link que me passou e realmente foi muito esclarecedor, principalmente por tratar do MVC clássico e o chamado MVC2 também! Um exemplo desses é um ótimo ponto de partida, muito obrigado!
marcobiscaro2112, juntando o link que vc e joyle passaram, mais os seus esclarecimentos, agora tenho uma base sólida quanto a teoria, bastando implementar o que aprendi (alias, o que aprendi com vocês todos), já que minha principal dúvida era mesmo quanto ao controlador.
Agora vou tentar uma implementação mais simples e tentar ir colocando mais funcionalidades até ter um código enxuto.
Mas acho que vocês ainda não se viram livres de mim, talvez eu volte pra tirar mais alguma dúvida! hehe
Não tenho como agradecer tamanha ajuda que vocês, do GUJ, tem me dado nos últimos meses, mas fica aqui o meu mais sincero agradecimento.
E espero, em breve, também poder contribuir com os outros membros.
Depois das dúvidas tiradas quanto a parte teórica, agora me restam algumas dúvidas quanto a implementação do con troller no mvc.
Agora já sei que o controlador deve atualizar o modelo com base nas ações do usuário na view, de acordo com a ação feita pelo usuário.
O gande problema é: como faço isso, sem o controlador receber uma referencia da view? até pode-se usar uma referencia da view no controlador, mas isso dificulta na hora de colocar uma nova view para o controlador tmb.
Tô pesquisando aqui e vendo que pode-se usar classes e interfaces para add listeners, mas ainda estou meio perdido.
Só lembrando que não quero me aproveitar de ninguem aqui, já que se trata apenas de estudos mesmo, quem quiser postar algum código para exemplificar, fico muito grato tmb, ou links para eu mesmo estudar.
No link que te passei acima tem tudo a respeito disso.
Na classe AbstractController tem um método addView() onde vc pode adicionar as suas views ao controller.
public void addView(CrudView view) {
registeredViews.add(view);
}
No meu caso toda view implementa a interface CrudView, por isso o parâmetro view é uma CrudView.
Leia todo o tutorial.
Baixe os fontes.
Estude a implementação.
Tire suas dúvidas.
E na interface CrudView:
import java.beans.PropertyChangeEvent;
public interface CrudView {
/**
* Called by the controller when it needs to pass along a property change
* from a model. Note that the method checks each GUI parameter to determine
* if the current value is already equal to the incoming value. If it is,
* the method will not reset the value. This is done to prevent looping from
* occurring when a model property is reset.
* @param evt The property change event
*/
public void modelPropertyChange(PropertyChangeEvent evt);
}
Estou lendo o artigo com mais atenção (realmente ontem dei apenas uma lida por cima, peço até desculpas por isso, mas foi devido a estar no trabalho).
Já baixei o fonte e estou estudando, e fiquei com mais uma dúvidas quanto à parte teórica: o controller serve apenas para receber métodos que serão executados na sua(s) view(s) e receber a lista de listeners? isso faria que, a partir desse tipo de implementação, eu poderia criar uma app desktop com o MVC “clássico” (onde a view é atualizada pelo model), e poder usar o model e o controller dessa mesma app para uma app web, por exemplo, apenas adicionando uma nova view?
E pelo que perebi tmb, view sempre recebe uma referência ao controller, para, a partir dai, poder executar os métodos adequados do controller, conforme a interação do usuário nos componentes da view. Isso é correto?
Tenho mais algumas dúvidas em relação a essa implementação, dúvidas mais técnicas, mas espero primeiro as respostas a estas perguntas para fazê-las.
Mais uma vez lhe peço desculpas joyle, por não ter lido com mais atenção o artigo que você postou, como já lhe disse, foi por falta de tempo ontem mesmo.
Muito obrigado pela sua ajuda, não imagina o quanto ela é importante pra mim!
Abraços!
Como você ainda está com muita dúvida na parte teórica, procure mais sobre o assunto.
O link abaixo já foi passado e tem o assunto bem discutido. http://www.guj.com.br/java/129277-perguntas-sobre-mvc-desktop-existe-solucao–mvpmvc-webobserver-e-exceptions
Estude mais também sobre OO (Orientação a Objetos), no inicio é meio difícil mesmo, mas depois você vai entendendo como tudo funciona.
Dá uma olhada nas apostilas da Caelum, são excelentes apostilas pra se estudar.
Faça o contrário. Faça a visão receber o controlador. Nesse caso, por exemplo, quando o usuário pressionar o botão “Atualizar” a visão chama o método para atualizar no controlador.
Assim o mesmo controlador pode estar em várias visões. A desvantagem é que a visão está acoplada ao controlador (o que, em geral, não representa um problema).
Faça o contrário. Faça a visão receber o controlador. Nesse caso, por exemplo, quando o usuário pressionar o botão “Atualizar” a visão chama o método para atualizar no controlador.
Assim o mesmo controlador pode estar em várias visões. A desvantagem é que a visão está bastante acoplada à visão (o que, em geral, não representa um problema).[/quote]
acho q vc quis dizer o controller ligado a visão certo?
acho q não fica aclopado
pois a view só conhecera o controller pela api
ou seja
não importa as chamadas pq a implementação a visão não sabe como é
ela só sabe os ingredientes, a eu sei q pra consultar um usuario, eu preciso dos dados, mas eu nao sei como consultar, mas o controller sabe
Se você for seguir a implementação do link que te passei, adicione as views ao controller também!
Na classe AbstractController há um método chamado propertyChange(PropertyChangeEvent evt) que implementa a interface PropertyChangeListener.
Esse método é utilizado para notificar suas views sempre que há uma alteração no model, que notifica o controller.
Olá pessoal, desculpem a demora em responder, correria de sempre, hehe.
Novamente muito obrigado pela colaboração de todos, é admirável a solidariedade do pessoal desse forum!
marcobiscaro2112 , estou seriamente pensando em fazer isso, só acho que fica um pouco fora do esquema que o joyle postou lá em cima, com a imagem (já que não há chamadas de métodos diretamente da view para o controller), porém, concordo com vc que isso parece não acarretar problemas, acho interessante começar dessa forma, e ir estudando mais, como o próprio joyle me indicou.
joyle, quanto ao model utilizei minha própria implementação do pattern observer, acho que ficou até bacana pra um iniciante (mas qualquer critica é sempre muito bem vinda!). Estou aqui tentando aprender com feras como vcs mesmo!
No link que te passei anteriormente com o exemplo, funciona praticamente da maneira que o marcobiscaro2112 citou, todas as views recebem uma referência do controller, isso caso vc queira que essa view notifique o controller de mudanças! Assim vc vai também adicionando ao controller suas views para que elas possam ser notificadas quanto ocorrer alguma mudança no seu model. Lembrando que a notificação acontece na implementação do método modelPropertyChange(PropertyChangeEvent evt).
[quote]joyle, quanto ao model utilizei minha própria implementação do pattern observer, acho que ficou até bacana pra um iniciante (mas qualquer critica é sempre muito bem vinda!). Estou aqui tentando aprender com feras como vcs mesmo!
Muito obrigado e um grande abraço a todos![/quote]
Você utilizou as classes do java! a Observer e Observable.
Aqui no fórum há algumas controvesas a respeito do uso dessa implementação da API. Como eu utilizo a implementação conforme te passei no link, não procurei saber muito a respeito desse assunto.
Alguns dizem que essas classes só devem ser usadas pela API mesmo, já outros dizem que nunca tiveram problemas.
De fato, eu não sei lhe dizer o correto a respeito disso, mas verifique sobre o assunto para ter maior segurança na sua implementação.
Quanto ao pattern Observer, não utilizei Observable da java.util não. Os nomes estão iguais, mas criei duas interfaces (tanto para Observer quanto para Observable) com os mesmo nomes, sendo que cada view e model implementam essas interfaces, e o próprio model é quem notifica a view sobre as suas mudanças de estado para view se atualizar (um esquema bem parecido com o Observer do java, talvez por isso você tenha confundido).
O ruim de se utilizar Observable é que mata a única herança disponível em java.
Quanto ao link que me passou, é show e bola! mas quanto a essa parte do controller atualizar a view, isso funciona bem pra app web, conforme o próprio artigo diz, estou implementando o MVC “original”, da SmallTalk.
Mas com certeza o artigo ajudou bastante, já que eu não sabia se era correto ter ref do controller na view, o que já clareou bem o caminho.
No entanto, ainda estou estudando mais para tentar desacoplar um pouco a view do conroller (se é que isso é possivel).
Vou terminar o controller aqui e continuar com as pesquisas, depois volto a postar por aqui.
Muito obrigado pela ajuda, e volto em breve na busca por novas soluções, hehe …
Um gande abraço e ótimo 2011 a todos!
