<br><br><div><span class="gmail_quote">On 3/29/07, <b class="gmail_sendername">Luis Motta Campos</b> <<a href="mailto:luismottacampos@yahoo.co.uk">luismottacampos@yahoo.co.uk</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Mar 28, 2007, at 11:37 PM, Alceu R. de Freitas Jr. wrote:<br>> Eu implementei uma bridge para o Controller, mas sinceramente não<br>> senti nenhuma vantagem em fazer isso<br>> (assumindo que eu implementei errado). Eu acabei por criar uma
<br>> superclasse que não definia nenhum método,<br>> apenas suas propriedades. Se for interessante, eu posso postar o<br>> código aqui.<br><br> Eu quero ver. :-) Por favor?<br><br>> O que me ajudou a implementar MVC foi realmente utilizar
<br>> Class::Publisher, que é uma implementação do<br>> padrão Observer. Com isso, consegui capturar os eventos dentro da<br>> própria classe da View e poder<br>> avisar quais outras classes de modificações no estado da View.
<br><br> Uh? Seu VIEW? Ele está fazendo papel de "Controller"? É função do<br>Controller tratar os eventos, e o fluxo de chamadas é sempre<br>Controller -> Model; Controller -> View, sendo que o Controller é o
<br>lugar onde você tem de implementar seu negócio.</blockquote><div><br>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?
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Acesso a dados deve estar todo implementado no Model, sendo<br>permitido ao Controller chamar métodos da interface pública para
<br>obter dados do Model, mas nunca calcular dados extras (como uma<br>intersecção, por exemplo) para uma nova chamada. Se você precisa de<br>uma intersecção dos seus dados, o Model deve ser responsável pelo<br>cálculo. O Controller chama apenas GETters.
<br> Finalmente, depois que o Controller alterou o Model conforme<br>solicitado pelo usuário, ele notifica o(s) View(s) para que eles<br>reflitam as modificações (gerando HTML ou alterando o estado do<br>"canvas" que o usuário vê).
<br><br> Este é o funcionamento definido na implementação do Smalltalk<br>(qualquer sabor), datada da década de '70, mais ou menos... ;-)<br><br>> O que realmente me deixa com dúvidas é que nenhuma das explicações
<br>> que encontrei na internet sobre MVC deixa<br>> explicíto como deve ser a comunicação entre as três classes (quem<br>> chama quem e em que situação). Por<br>> exemplo, se eu tenho um evento na View, poderia chamar o Model
<br>> diretamente? Ou teria que fazer isso pelo<br>> Controller? O mais perto que cheguei disso foi implementar uma<br>> superclasse abstrata da View para<br>> ligar o Model a ela. Se alguém tiver um link para informar isso,
<br>> fico muito grato.<br><br> Eu descrevi aproximadamente o fluxo de informações que você deve<br>usar acima. :-) Espero que isso ajude. Por favor pergunte o que for<br>necessário.<br><br> Views NUNCA GERAM EVENTOS. "Tenho um evento na View" é ter dois
<br>problemas: a) você ainda não entendeu MVC; b) você implementou o<br>padrão de projeto errado. ;-) Eventos (mesmo que gerados pela<br>interface de usuário) devem ser encaminhados diretamente para o<br>Controller.<br><br>
Talvez seja exatamente o que você esteja fazendo neste momento,<br>mas você ainda não está enxergando o MVC do ponto de vista correto. A<br>View (vamos considerar uma interface gráfica interativa /statefull/)<br>geralmente vai receber eventos (um clique do usuário, por exemplo).
<br>Ela não gerou o evento. O usuário é que gerou o evento. A View pode<br>até ser a primeira a receber a informação sobre o evento (isto é<br>Event-Driven Software Design – tudo sob controle). O dever da View é<br>encaminhar (com uma chamada na interface pública do Controller) o
<br>evento *imediatamente*. Desta forma, estabelecemos /descolamento/<br>entre o View (implementado event-driven, no seu caso) e o Controller.<br>Se algum dia você quiser trocar o Controller da sua aplicação, sabe<br>que basta implementar novamente o Controller, e manter a interface
<br>com o View.<br><br> Da mesma forma, a comunicação entre o Controller e o Model deve<br>ser dosada através de interfaces bem definidas (que você vai refinar<br>com tempo e paciência, não se preocupe muito com "fechar" isso antes
<br>de ter a terceira versão do seu sistema).<br><br> Uma observação interessante: algumas correntes de filosofia de<br>projeto sobre o MVC diz que é válido que o View consulte o Model,<br>desde que ele realize apenas operações de leitura, e nunca altere o
<br>estado do modelo. Isso facilita a implementação de Views, mas pode te<br>comprometer um pouco a interface pública do Model. Eu recomendo<br>manter duas interfaces públicas para o seu Model: uma read-only, para<br>o View consultar, e outra read-write (quando aplicável) para o
<br>Controller.<br><br> Claro, tudo isso é muito genérico e eu tenho certeza de que você<br>pode ter problemas. Como eu disse, pergunte o que precisar.<br><br> Putamplexos!<br>--<br>Luis Motta Campos (a.k.a. Monsieur Champs) is a software engineer,
<br>Perl fanatic evangelist, and amateur {cook, photographer}<br><br><br>_______________________________________________<br>Cascavel-pm mailing list<br><a href="mailto:Cascavel-pm@pm.org">Cascavel-pm@pm.org</a><br><a href="http://mail.pm.org/mailman/listinfo/cascavel-pm">
http://mail.pm.org/mailman/listinfo/cascavel-pm</a><br></blockquote></div><br><br clear="all"><br>-- <br>Lindolfo "Lorn" Rodrigues<br>- <a href="http://www.slackwarezine.com.br">www.slackwarezine.com.br</a><br>-
<a href="http://lornlab.org">http://lornlab.org</a><br>- <a href="http://sao-paulo.pm.org">http://sao-paulo.pm.org</a><br>use Catalyst;