[Cascavel-pm] WxPerl e MVC

Luis Motta Campos luismottacampos em yahoo.co.uk
Quinta Março 29 00:19:34 PDT 2007


On Mar 28, 2007, at 11:37 PM, Alceu R. de Freitas Jr. wrote:
> Eu implementei uma bridge para o Controller, mas sinceramente não  
> senti nenhuma vantagem em fazer isso
> (assumindo que eu implementei errado). Eu acabei por criar uma  
> superclasse que não definia nenhum método,
> apenas suas propriedades. Se for interessante, eu posso postar o  
> código aqui.

   Eu quero ver. :-) Por favor?

> O que me ajudou a implementar MVC foi realmente utilizar  
> Class::Publisher, que é uma implementação do
> padrão Observer. Com isso, consegui capturar os eventos dentro da  
> própria classe da View e poder
> avisar quais outras classes de modificações no estado da View.

   Uh? Seu VIEW? Ele está fazendo papel de "Controller"? É função do  
Controller tratar os eventos, e o fluxo de chamadas é sempre  
Controller -> Model; Controller -> View, sendo que o Controller é o  
lugar onde você tem de implementar seu negócio.
   Acesso a dados deve estar todo implementado no Model, sendo  
permitido ao Controller chamar métodos da interface pública para  
obter dados do Model, mas nunca calcular dados extras (como uma  
intersecção, por exemplo) para uma nova chamada. Se você precisa de  
uma intersecção dos seus dados, o Model deve ser responsável pelo  
cálculo. O Controller chama apenas GETters.
   Finalmente, depois que o Controller alterou o Model conforme  
solicitado pelo usuário, ele notifica o(s) View(s) para que eles  
reflitam as modificações (gerando HTML ou alterando o estado do  
"canvas" que o usuário vê).

   Este é o funcionamento definido na implementação do Smalltalk  
(qualquer sabor), datada da década de '70, mais ou menos... ;-)

> O que realmente me deixa com dúvidas é que nenhuma das explicações  
> que encontrei na internet sobre MVC deixa
> explicíto como deve ser a comunicação entre as três classes (quem  
> chama quem e em que situação). Por
> exemplo, se eu tenho um evento na View, poderia chamar o Model  
> diretamente? Ou teria que fazer isso pelo
> Controller? O mais perto que cheguei disso foi implementar uma  
> superclasse abstrata da View para
> ligar o Model a ela. Se alguém tiver um link para informar isso,  
> fico muito grato.

   Eu descrevi aproximadamente o fluxo de informações que você deve  
usar acima. :-) Espero que isso ajude. Por favor pergunte o que for  
necessário.

   Views NUNCA GERAM EVENTOS. "Tenho um evento na View" é ter dois  
problemas: a) você ainda não entendeu MVC; b) você implementou o  
padrão de projeto errado. ;-) Eventos (mesmo que gerados pela  
interface de usuário) devem ser encaminhados diretamente para o  
Controller.

   Talvez seja exatamente o que você esteja fazendo neste momento,  
mas você ainda não está enxergando o MVC do ponto de vista correto. A  
View (vamos considerar uma interface gráfica interativa /statefull/)  
geralmente vai receber eventos (um clique do usuário, por exemplo).  
Ela não gerou o evento. O usuário é que gerou o evento. A View pode  
até ser a primeira a receber a informação sobre o evento (isto é  
Event-Driven Software Design – tudo sob controle). O dever da View é  
encaminhar (com uma chamada na interface pública do Controller) o  
evento *imediatamente*. Desta forma, estabelecemos /descolamento/  
entre o View (implementado event-driven, no seu caso) e o Controller.  
Se algum dia você quiser trocar o Controller da sua aplicação, sabe  
que basta implementar novamente o Controller, e manter a interface  
com o View.

   Da mesma forma, a comunicação entre o Controller e o Model deve  
ser dosada através de interfaces bem definidas (que você vai refinar  
com tempo e paciência, não se preocupe muito com "fechar" isso antes  
de ter a terceira versão do seu sistema).

   Uma observação interessante: algumas correntes de filosofia de  
projeto sobre o MVC diz que é válido que o View consulte o Model,  
desde que ele realize apenas operações de leitura, e nunca altere o  
estado do modelo. Isso facilita a implementação de Views, mas pode te  
comprometer um pouco a interface pública do Model. Eu recomendo  
manter duas interfaces públicas para o seu Model: uma read-only, para  
o View consultar, e outra read-write (quando aplicável) para o  
Controller.

   Claro, tudo isso é muito genérico e eu tenho certeza de que você  
pode ter problemas. Como eu disse, pergunte o que precisar.

   Putamplexos!
--
Luis Motta Campos (a.k.a. Monsieur Champs) is a software engineer,
Perl fanatic evangelist, and amateur {cook, photographer}




Mais detalhes sobre a lista de discussão Cascavel-pm