[Cascavel-pm] WxPerl e MVC

Eden Cardim edencardim em gmail.com
Quinta Março 29 11:27:57 PDT 2007


On 3/29/07, Luis Motta Campos <luismottacampos em yahoo.co.uk> wrote:
>    O que torna a maior parte das suas implementações de MVC duvidosas.
>    O MVC é Controller-centric, o Adaptor é uma "peça no meio do
> percurso".

Hmm, não sei, acho que isso está sujeito a debate. Pra mim, o objetivo
do MVC é desacoplar Models de Views, e esses dois do comportamento
geral da aplicação (definido por um ou mais Controllers) para
possibilitar o reaproveitamento de componentes. Assim, para mudar a
forma com que um Model é visualizado, basta implementar uma nova View.
Para mudar o que é visualizado através de uma View, basta implementar
um novo Model. Para mudar o comportamento geral da aplicação, basta
implementar um novo Controller. As mudanças de Views e Models podem
até estar embutidos na lógica do Controller, se for necessário. E,
finalmente, todos os três tipos de componentes podem ser
reaproveitados em um novo sistema. Pra mim, a forma com que esses três
componentes implementam o comportamento desejado não interessa, desde
que sigam o contrato proposto.

>    Se isso não foi o bastante para você sacar a diferença, leia o
> email que eu respondi para o Alceu, descrevendo o fluxo de
> processamento esperado de um MVC. Basicamente:
>
>    1. User gera evento;
>    2. Evento capturado pelo View (quando View implementa "Event-Driven")
>    3. View Transmite Evento ao Controller
>    4. Controller processa Evento
>    5. Controller acessa dados no Model
>    6. Controller transmite alterações para o View, forçando "redesenho"
>
>    Ou, alternativamente:
>    6. Controller notifica alterações no Model para o View
>    7. View "redesenha" de acordo com o Model

De novo, acho esse fluxo sujeito a debate. Um Model, IMHO, não é
constituído apenas de dados, mas também da lógica necessária para
processá-los: consultas,  algoritmos, etc, etc. E o User não precisa
ser necessarimente um humano, nem um gerador de eventos. Assim, a
etapa 5 que você descreve não é necessariamente apenas para acesso a
dados, inclusive, pode até não haver acesso nenhum a dados, apenas
processamento, ou uma combinação dos dois (que é o que sempre acontece
por trás das cenas). É como se o Controller fosse uma Dispatch Table
com um pouco de inteligência agregada.

-- 
Eden Cardim
Instituto Baiano de Biotecnologia
Núcleo de Biologia Computacional e Gestão de Informações Biotecnológicas
Laboratório de Bioinformática
--
"you seem to think that 'close enough' is close enough...
please learn to be 'literal' around programming."
merlyn - on irc.freenode.net#perl


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