MVC e Camadas
From Fragmental Bliki
Conteúdo |
Introdução
A Arquitetura de Camadas é muito utilizada para separar responsabilidades em uma aplicação moderna. Apesar de a idéia da divisão de uma aplicação em Camadas ter se popularizado nos anos 90, muitos desenvolvedores ainda não conhecem a técnica a fundo, boa parte por documentação ineficiente sobre este Padrão Arquitetural.
Junto com a popularização da Arquitetura de Camadas, ressurgiu o modelo MVC de desenvolvimento. Este modelo foi criado em Smalltalk e traz simplicidade e coerência à interfaces.
Um problema com a popularização simultânea destes dois Padrões Arquiteturais é que estes passaram a ser eternamente confundidos. O objetivo deste breve artigo é mostrar como MVC e Camadas são conceitos diferentes, que podem ser aplicados em conjunto ou não.
Nota: O termo ‘componente’ é utilizado aqui para significar qualquer artefato de software. Pode ser substituído por classe, camada, objeto ou mesmo um componente no sentido dado por Component-Based Design (CBD).
Camadas: Separação Entre Componentes
Para melhor organizar a manter componentes, é crucial que sejam separados por algum critério. Isolando-os em grupos é possível diminuir o acoplamento entre os componentes, fazendo com que as mudanças em um grupo não impactem muito em outro grupo.
Entre as diversas formas possíveis de separar os componentes, está a técnica de Camadas. Ao separar componentes em grupos chamados Camadas (Layers em inglês), o projetista agrupa componentes por responsabilidade em comum que possuam.
Uma aplicação Java EE tradicional, por exemplo, usa o modelo de 3 Camadas: Apresentação, Negócios e Persistência. Na Camada de Apresentação estão todas as classes e demais artefatos (como páginas JSP) relacionados com a interação entre o usuário e a aplicação. A Camada de Negócios contêm a modelagem do domínio do problema em classes de negócio e a Camada de Persistência contém as classes com conhecimento sobre como persistir objetos no banco de dados (por exemplo, DAOs).
O diagrama abaixo mostra os objetos em uma aplicação simples. Neste caso não há separação lógica qualquer.
Aplicando a técnica de Camadas, vamos agrupar os objetos com responsabilidade semelhante.
Utilizando Camadas o projetista tem um critério a utilizar quando decide agrupar duas ou mais classes, mas o uso de Camadas não diz nada sobre como estes grupos se comunicam. O máximo que o uso de Camadas diz é sobre se estas são transparentes (ou abertas) ou opacas (fechadas). Camadas transparentes não evitam que uma superior enxergue a inferior, as opacas sim.
As Camadas promovem o encapsulamento (uma Camada não vai saber o que tem dentro da outra) e a coesão (componentes parecidos ficam no mesmo grupo).
MVC: Interaçã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.
Conclusão
Pela escassez de material disponível é compreensível a confusão gerada pelos conceitos. De qualquer forma, é possível reduzir as diferenças a algo simples de lembrar:
Camadas dizem como agrupar os componentes. MVC diz como interagem os componentes.
E lembre-se sempre que componentes neste contexto se refere a qualquer artefato de software: classes, páginas dinâmicas, scripts, objetos...
Mesmo sendo a literatura sobre Camadas e MVC pouca, é o suficiente para entender melhor como estes conceitos se relacionam. Confira nas referências algumas fontes importantes para melhorar o entendimento sobre estes dois padrões Arquiteturais tão usados, mal e bem.
Referências
Desenvolvendo Sistemas OO Com Padrões de Negócio
