MVC: INTEGRAÇÃO ENTRE COMPONENTES

Partindo do ponto que temos os nossos componentes separados de alguma forma, utilizando Camadas ou não, precisamos de um modelo de interação entre estes.
A maneira mais natural de conduzir esta interação é não definir regra alguma. Agindo desta forma os componentes podem falar entre si sem qualquer limitação ou protocolo. Este modelo é muito utilizado e relativamente eficiente, mas existe um aspecto de um sistema que normalmente não fica bem desta forma: interfaces gráficas.
Interfaces gráficas geralmente exibem o estado dos objetos de uma aplicação, e geralmente isso deve ser feito em ‘tempo real’ (com o perdão do mau uso do termo). Uma alteração no estado do objeto deve ser imediatamente refletida na tela visível ao usuário.
Outro aspecto é que a interface recebe os estímulos vindos do usuário e os deve propagar para os objetos de negócio. Se cada componente numa tela gráfica for responsável por estimular os objetos certos o código tende a ficar repetitivo e difícil de manter. Um exemplo clássico são interfaces gráficas construídas em tecnologias RAD como Visual Basic e Delphi onde diversas regras e rotinas são contidas dentro dos botões e demais controles no formulário. Ao alterar uma destas rotinas é necessário alterar o código do controle gráfico e ao alterar o controle gráfico é necessário tocar no código da rotina, o que não é desejável já que são aspectos diferentes de uma aplicação.
Uma solução criada nos anos 70 é o chamado Modelo MVC (de Model-View-Controller). Este modelo consiste no bom uso integrado de alguns Design Patterns (Padrões de Projeto) clássicos, como Observer e Strategy.
Num Modelo MVC, nossos componentes são divididos em 3, os já citados View, Model e Controller. A View é a parte exposta, o Controller é o controle sobre a comunicação que vem do usuário para o sistema e o Model representa o estado do sistema.
Note que o modelo MVC não precisa ser utilizado apenas em interfaces gráficas. Qualquer tipo de comunicação entre componentes, visuais ou não, pode ser regido por este.
O MVC se baseia em 2 princípios fortes.

• O Controller Despacha as Solicitações ao Model

A View observa o Model

Estes princípios definem a comunicação. O estímulo vindo do usuário (ou de outro componente se você está usando MVC fora de uma interface gráfica) vai para o Controller que é o componente com inteligência o suficiente para saber qual operação invocar no Model. A operação invocada pode efetuar a mudança de estado no model. Como a View observa este, assim que a mudança de estado for realizada ela é atualizada. Então o MVC em si não traz mais do que 2 regras básicas para a comunicação entre componentes, não diz o que estes componentes contem. Integrando Como já mencionado, é possível e muitas vezes desejável integrar a técnica de Camadas com o modelo de interação provido pelo MVC. Quando estamos lidando com aplicações monolíticas (não compostas por serviços –como em SOA- ou por componentes – neste caso estamos falando de componentes de negócio, como definido por CBD). A partir do momento em que dividimos os nossos componentes em Camadas podemos aplicar o MVC nestas. Geralmente isto é feito definindo a Camada de Negócios como o Model, a Apresentação como a View. O componente Controller exige um pouco mais de controle. Na maioria dos casos pode-se definir o Controller dentro da Camada de Apresentação. Esta Camada ficaria responsável então por mostrar o estado do Model ao usuário e receber as requisições deste. Algumas vezes, entretanto, é necessário que o Controller fique isolado desta. Este é o caso, por exemplo, quando possuímos mais de uma interface, como Swing e HTML. Neste caso, pode-se utilizar uma Camada que quase sempre está implícita, a Camada de Aplicação.