MVC e Camadas

From Fragmental Bliki

Contedo
1 Introduo 2 Camadas: Separao Entre Componentes 3 MVC: Interao Entre Componentes 4 Concluso 5 Referncias

Introduo
A Arquitetura de Camadas muito utilizada para separar responsabilidades em uma aplicao moderna. Apesar de a idia da diviso de uma aplicao em Camadas ter se popularizado nos anos 90, muitos desenvolvedores ainda no conhecem a tcnica a fundo, boa parte por documentao ineficiente sobre este Padro Arquitetural. Junto com a popularizao da Arquitetura de Camadas, ressurgiu o modelo MVC de desenvolvimento. Este modelo foi criado em Smalltalk e traz simplicidade e coerncia interfaces. Um problema com a popularizao simultnea destes dois Padres Arquiteturais que estes passaram a ser eternamente confundidos. O objetivo deste breve artigo mostrar como MVC e Camadas so conceitos diferentes, que podem ser aplicados em conjunto ou no. Nota: O termo componente utilizado aqui para significar qualquer artefato de software. Pode ser substitudo por classe, camada, objeto ou mesmo um componente no sentido dado por Component-Based Design (CBD).

Camadas: Separao Entre Componentes

Para melhor organizar a manter componentes, crucial que sejam separados por algum critrio. Isolando-os em grupos possvel diminuir o acoplamento entre os componentes, fazendo com que as mudanas em um grupo no impactem muito em outro grupo. Entre as diversas formas possveis de separar os componentes, est a tcnica de Camadas. Ao separar componentes em grupos chamados Camadas (Layers em ingls), o projetista agrupa componentes por responsabilidade em comum que possuam. Uma aplicao Java EE tradicional, por exemplo, usa o modelo de 3 Camadas: Apresentao, Negcios e Persistncia. Na Camada de Apresentao esto todas as classes e demais artefatos (como pginas JSP) relacionados com a interao entre o usurio e a aplicao. A Camada de Negcios contm a modelagem do domnio do problema em classes de negcio e a Camada de Persistncia contm as classes com conhecimento sobre como persistir objetos no banco de dados (por exemplo, DAOs). O diagrama abaixo mostra os objetos em uma aplicao simples. Neste caso no h separao lgica qualquer.

Aplicando a tcnica de Camadas, vamos agrupar os objetos com responsabilidade semelhante.

Utilizando Camadas o projetista tem um critrio a utilizar quando decide agrupar duas ou mais classes, mas o uso de Camadas no diz nada sobre como estes grupos se comunicam. O mximo que o uso de Camadas diz sobre se estas so transparentes (ou abertas) ou opacas (fechadas). Camadas transparentes no evitam que uma superior enxergue a inferior, as opacas sim. As Camadas promovem o encapsulamento (uma Camada no vai saber o que tem dentro da outra) e a coeso

(componentes parecidos ficam no mesmo grupo).

MVC: Interao Entre Componentes

Partindo do ponto que temos os nossos componentes separados de alguma forma, utilizando Camadas ou no, precisamos de um modelo de interao entre estes. A maneira mais natural de conduzir esta interao no definir regra alguma. Agindo desta forma os componentes podem falar entre si sem qualquer limitao ou protocolo. Este modelo muito utilizado e relativamente eficiente, mas existe um aspecto de um sistema que normalmente no fica bem desta forma: interfaces grficas. Interfaces grficas geralmente exibem o estado dos objetos de uma aplicao, e geralmente isso deve ser feito em tempo real (com o perdo do mau uso do termo). Uma alterao no estado do objeto deve ser imediatamente refletida na tela visvel ao usurio. Outro aspecto que a interface recebe os estmulos vindos do usurio e os deve propagar para os objetos de negcio. Se cada componente numa tela grfica for responsvel por estimular os objetos certos o cdigo tende a ficar repetitivo e difcil de manter. Um exemplo clssico so interfaces grficas construdas em tecnologias RAD como Visual Basic e Delphi onde diversas regras e rotinas so contidas dentro dos botes e demais controles no formulrio. Ao alterar uma destas rotinas necessrio alterar o cdigo do controle grfico e ao alterar o controle grfico necessrio tocar no cdigo da rotina, o que no desejvel j que so aspectos diferentes de uma aplicao. Uma soluo criada nos anos 70 o chamado Modelo MVC (de Model-View-Controller). Este modelo consiste no bom uso integrado de alguns Design Patterns (Padres de Projeto) clssicos, como Observer e Strategy. Num Modelo MVC, nossos componentes so divididos em 3, os j citados View, Model e Controller. A View a parte exposta, o Controller o controle sobre a comunicao que vem do usurio para o sistema e o Model representa o estado do sistema. Note que o modelo MVC no precisa ser utilizado apenas em interfaces grficas. Qualquer tipo de comunicao entre componentes, visuais ou no, pode ser regido por este. O MVC se baseia em 2 princpios fortes. O Controller Despacha as Solicitaes ao Model

A View observa o Model

Estes princpios definem a comunicao. O estmulo vindo do usurio (ou de outro componente se voc est usando MVC fora de uma interface grfica) vai para o Controller que o componente com inteligncia o suficiente para saber qual operao invocar no Model. A operao invocada pode efetuar a mudana de estado no model. Como a View observa este, assim que a mudana de estado for realizada ela atualizada. Ento o MVC em si no traz mais do que 2 regras bsicas para a comunicao entre componentes, no diz o que estes componentes contem.

Integrando Como j mencionado, possvel e muitas vezes desejvel integrar a tcnica de Camadas com o modelo de interao provido pelo MVC. Quando estamos lidando com aplicaes monolticas (no compostas por servios como em SOA- ou por componentes neste caso estamos falando de componentes de negcio, 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 Negcios como o Model, a Apresentao 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 Apresentao. Esta Camada ficaria responsvel ento por mostrar o estado do Model ao usurio e receber as requisies deste. Algumas vezes, entretanto, necessrio que o Controller fique isolado desta. Este o caso, por exemplo, quando possumos mais de uma interface, como Swing e HTML. Neste caso, pode-se utilizar uma Camada que quase sempre est implcita, a Camada de Aplicao.

Concluso
Pela escassez de material disponvel compreensvel a confuso gerada pelos conceitos. De qualquer forma, possvel reduzir as diferenas 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, pginas dinmicas, scripts, objetos... Mesmo sendo a literatura sobre Camadas e MVC pouca, o suficiente para entender melhor como estes conceitos se relacionam. Confira nas referncias algumas fontes importantes para melhorar o entendimento sobre estes dois padres Arquiteturais to usados, mal e bem.

Referncias
Desenvolvendo Sistemas OO Com Padres de Negcio Arquitetura de Camadas em Java EE Patterns of Enterprise Application Architecture Retirado de "http://fragmental.com.br/wiki/index.php/MVC_e_Camadas"

Est pgina foi modificada pela ltima vez em 02:27, 22 Junho 2007. Esta pgina foi acessada 30 590 vezes. Contedo disponvel sob Attribution-Noncommercial-Share Alike 3.0 . Poltica de privacidade Sobre a Fragmental Bliki Disclaimers