[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