[Cascavel-pm] WxPerl e MVC

[Lorn]

On 3/29/07, Luis Motta Campos <luismottacampos em yahoo.co.uk> wrote:
>
> 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.


Concordo que o Controller tenha que tratar eventos, mas regras de negocio
não é no model? a função do controller não é apenas " controlar"? tipo,
Chama o Model, pega o resultado do model e joga na view?

   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}
>
>
> _______________________________________________
> Cascavel-pm mailing list
> Cascavel-pm em pm.org
> http://mail.pm.org/mailman/listinfo/cascavel-pm
>



-- 
Lindolfo "Lorn" Rodrigues
- www.slackwarezine.com.br
- http://lornlab.org
- http://sao-paulo.pm.org
use Catalyst;
-------------- Próxima Parte ----------
Um anexo em HTML foi limpo...
URL: http://mail.pm.org/pipermail/cascavel-pm/attachments/20070329/f6b25fe5/attachment.html