Padrões de Projeto : O modelo MVC - Model View  Controller

Os padrões de projeto são  muito úteis para resolver problemas de modelagem de projetos se usados de forma adequada. Mas o que são estes benditos padrões de projetos ou Design Patterns ?

Padrões de projetos  são soluções para problemas que alguém um dia teve e resolveu aplicando um modelo que foi documentado e que você pode adaptar integralmente ou de acordo com necessidade de sua solução. Vou abordar neste artigo o padrão de modelo MVC que tem por objetivo básico separar a lógica de negócio da apresentação.

Nota: No Super DVD .NET você encontra a edição eletrônica do bestseller  "Design Patterns" - publicação voltada a desenvolvedores que utilizam a metodologia de orientação a objetos.

O grande desafio das equipes de desenvolvimento de aplicações é cada vez mais produzir aplicativos seguros , eficientes , de fácil manutenção , reutilizáveis e em prazos cada vez menores.

O paradigma da orientação a objetos tem tido um grande avanço nestes últimos tempos (leia-se Java e agora .NET) , tanto é que , segundo o Partner Group , dentre as tecnologias que vão sobreviver no mercado nos próximos anos estão Java e .NET. Você então já percebeu por que a Microsoft lançou a tecnologia .NET e tornou orientada a objetos o bom e velho Visual Basic , trazendo consigo o C# para quem usa Java.  Estima-se que a partir de agora será impensável produzir aplicações que não sejam orientadas a objetos desde sua concepção.

O sucesso para o desenvolvimento de aplicações com tecnologia orientada a objetos esta intimamente ligada  á arquitetura que vamos usar para construir a aplicação. A tendência indica que esta arquitetura estará baseada na organização da aplicação em camadas e na observação dos padrões utilizados pelo mercado.

A organização em camadas é a chave para a independência entre os componentes e esta independência é que vai atingir os objetivos de eficiência , escalabilidade , reutilização e facilidade de manutenção.

Num primeiro instante produzir aplicativos multicamadas pode parecer mais complexo por isto vou procurar mostrar como evoluímos para chegar a esta solução. O termo camada pode significar uma separação física ou uma camada lógica , no nosso caso , a produção de software vamos considerar camada como uma referência a separação de responsabilidades.

Aplicações monolíticas

Nos tempos antigos do reinado do grande porte e do computador pessoal independente um aplicativo era desenvolvido para ser usado  em uma única máquina . Geralmente este aplicativo continha todas a funcionalidades em um único módulo gerado por uma grande quantidade de linhas de código e de manutenção nada fácil.  A entrada do usuário , verificação , lógica de negócio e acesso a banco de dados estava presente em um mesmo lugar. Podemos definir este tipo de aplicação como aplicação de uma camada ou monolítica , esquematizada a seguir :

Aplicações em duas camadas

A necessidade de compartilhar a lógica de acesso a dados entre vários usuários simultâneos fez surgir as aplicações em duas camadas. Nesta estrutura a base de dados foi colocada em uma máquina específica, separada das máquinas que executavam as aplicações. Nesta abordagem temos aplicativos instalados em estações clientes contendo toda a lógica da aplicação (clientes ricos ou gordos). Um grande problema neste modelo é o gerenciamento de versões pois para cada alteração os aplicativos precisam ser atualizados em todas as máquinas clientes.

Aplicações em três camadas

Com o advento da internet houve um movimento para separar a lógica de negócio da interface com o usuário. A idéia é que os usuários da WEB possam acessar sa mesmas aplicações sem ter que instalar estas aplicações em suas máquinas locais. Como a lógica do aplicativo , inicialmente contida no cliente rico não reside mais na máquina do usuário este tipo de cliente passo a ser chamado de cliente pobre ou magro.(thin).

Neste modelo o aplicativo é movido para o Servidor e  um navegador Web é usado como um cliente magro. O aplicativo é executado em servidores Web com os quais o navegador Web se comunica e gera o código HTML para ser exibido no cliente.

Neste modelo a lógica de apresentação esta separada em sua própria camada lógica e física.A separação em camadas lógicas torna os sistemas mais flexíveis permitindo que as partes possam ser alteradas de forma independente.  As funcionalidades da camada de negócio podem ser divididas em classes e essas classes podem ser agrupadas em pacotes ou componentes reduzindo as dependências entre as classes e pacotes ; podem ser reutilizadas por diferentes partes do aplicativo e até por aplicativos diferentes. O modelo de 3 camadas tornou-se a arquitetura padrão para sistemas corporativos com base na Web.

A modelagem orientada a objetos ajuda a promover a modularidade pois os objetos encapsulam seus dados (propriedades , estados) e oferecem funcionalidades através de seus métodos. Projetando-se de forma adequada os objetos podem ter reduzidas as dependências entre si ficando assim fracamente acoplados e serão mais fáceis de manter e evoluir.

O padrão MVC

O modelo de três camadas fisícas ( 3-tier ) divide um aplicativo de modo que a lógica de negócio resida no meio das três camadas físicas. Isto é chamado de camada física intermediária ou camada física de negócios. A maior parte do código escrito reside na camada de apresentação e de negócio.

A arquitetura MVC - (Modelo Visualização Controle) fornece uma maneira de dividir a funcionalidade envolvida na manutenção e apresentação dos dados de uma aplicação. A arquitetura MVC não é nova e foi originalmente desenvolvida para mapear as tarefas tradicionais de entrada , processamento e saída para o modelo de interação com o usuário. Usando o padrão MVC fica fácil mapear esses conceitos no domínio de aplicações Web multicamadas.

Na arquitetura MVC o modelo representa os dados da aplicação e as regras do negócio que governam o acesso e a modificação dos dados. O modelo mantém o estado persistente do negócio e fornece ao controlador a capacidade de acessar as funcionalidades da aplicação encapsuladas pelo próprio modelo.

Um componente de visualização renderiza o conteúdo de uma parte particular do modelo e encaminha para o controlador as ações do usuário; acessa também os dados do modelo via controlador e define como esses dados devem ser apresentados.

Um controlador define o comportamento da aplicação , é ele que interpreta as ações do usuário e as mapeia para chamadas do modelo. Em um cliente de aplicações Web essas ações do usuário poderiam ser cliques de botões ou seleções de menus. As ações realizadas pelo modelo incluem ativar processos de negócio ou alterar o estado do modelo. Com base na ação do usuário e no resultado do processamento do modelo , o controlador seleciona uma visualização a ser exibida como parte da resposta a solicitação do usuário. Há normalmente um controlador para cada conjunto de funcionalidades relacionadas.

A arquitetura de 3 camadas que esta representada abaixo é uma implementação do modelo MVC . O modelo MVC esta preocupado em separar a informação de sua apresentação.

Camada de apresentação ou visualização - Não esta preocupada em como a informação foi obtida ou onde ela foi obtida apenas exibe a informação.

Camada de lógica da Aplicação - É o coração da aplicação . Responsável por tudo que a aplicação vai fazer.

Camada de Controle - determina o fluxo da apresentação servindo como uma camada intermediária entre a camada de apresentação e a lógica.

Vantagens do modelo MVC :

  1. Como o modelo MVC gerencia múltiplos visualizadores usando o mesmo modelo é fácil manter , testar e atualizar sistemas múltiplos
  2. É muito simples incluir novos clientes apenas incluindo seus visualizadores e controles
  3. Torna a aplicação escalável
  4. É possível ter desenvolvimento em paralelo para o modelo , visualizador e controle pois são independentes.

Desvantagens do modelo MVC:

  1. Requer uma quantidade maior de tempo para analisar e modelar o sistema
  2. Requer pessoal especializado
  3. Não é aconselhável para pequenas aplicações

Conclusão

O padrão MVC está relacionado com a arquitetura da aplicação e em como os componentes se comunicam.

A arquitetura em 3 camadas esta relacionada com a arquitetura do Sistema onde você divide as responsabilidades em camada de apresentação, de negócio e de acesso aos dados.

Os conceitos se complementam e podem coexistir harmonicamente sem conflitos. Você pode usar o padrão MVC para a camada de apresentação de uma arquitetura em camadas. (O padrão MVC também pode ser aplicado em aplicações usando apenas uma camada.)

Na arquitetura em 3 camadas a comunicação entre as camadas é bidirecional e sempre passa pela camada intermediária

No padrão MVC a comunicação é unidirecional.

A regra fundamental em uma arquitetura em três camadas é que a camada de apresentação (cliente) nunca se comunica diretamente com a camada de dados, em um modelo de três camadas toda a comunicação deve passar pela camada de intermediária.

Conceitualmente a arquitetura de três camadas é linear.

No entanto, a arquitetura MVC é triangular: a view envia atualizações para o controlador, o controlador atualiza o modelo, e a view é atualizada diretamente do modelo.

Martin Fowler define um padrão "Application Layered" como uma forma de organizar uma aplicação de software em um conjunto de camadas lógicas com a finalidade de gerenciar dependências e criar componentes plugáveis.

O padrão MVC define uma abordagem para a interação entre a apresentação e os componentes de domínio do negócio. Além disso, o padrão MVC não está relacionado com outros problemas de aplicação, como persistência, segurança e escalabilidade.

Fowler e Trowbridge consideram a arquitetura "n-tier" como um padrão de implantação: uma forma de organizar a infraestrutura para a execução das aplicações desenvolvidas. Segundo eles, uma aplicação web pode ser implantada em três camadas: cliente, aplicações web e de dados.

Basicamente, eles afirmam que alguns componentes da aplicação podem ser implementados em um conjunto de máquinas do cliente, outros componentes em um conjunto de servidores de aplicativos web e outros componentes em um conjunto de hosts do servidor de dados.

Considerando estes três níveis, o padrão MVC define uma abordagem para conectar componentes de apresentação na camada do cliente (por exemplo, um telefone celular ou aplicação de internet), com alguns componentes de serviços na camada de aplicação web. O MVC não define nada sobre a interação entre a camada de aplicação web e a camada de dados.

Logo :  MVC não é 3 camadas.

No próximo artigo vou mostrar como implementar o modelo MVC em uma aplicação VB.NET em 3 camadas.

Acompanhe a continuação no link :  VB.NET - Criando uma aplicação em 3 camadas ( MVC )

João 11:25 Declarou-lhe Jesus: Eu sou a ressurreição e a vida; quem crê em mim, ainda que morra, viverá;

João 11:26 e todo aquele que vive, e crê em mim, jamais morrerá. Crês isto?

Até o próximo artigo. Aguarde...

Gostou ?   Compartilhe no Facebook   Compartilhe no Twitter

Veja os Destaques e novidades do SUPER DVD Visual Basic  (sempre atualizado) : clique e confira !

Quer migrar para o VB .NET ?

Veja mais sistemas completos para a plataforma .NET no Super DVD .NET , confira...

Quer aprender C# ??

Chegou o Super DVD C#  com exclusivo material de suporte e vídeo aulas com curso básico sobre C#.

Veja também os Cursos com vídeo aulas e projetos exemplos:

Referências:

José Carlos Macoratti