As aplicações, de um modo geral, apresentam conteúdo para os usuários em numerosas páginas, contendo uma diversidade de dados.
As equipes responsáveis pelo projeto, implementação e manutenção das aplicações são compostas de indivíduos com diferentes capacitações.
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.
2) Histórico
O padrão MVC tem suas raízes no Smalltalk onde ele foi aplicado originalmente para mapear os tradicionais: “input, processing and output” para um modelo de interação com o usuário baseado em interface gráfica.
3) O Problema
Atualmente, mais do que nunca, as aplicações nas organizações necessitam suportar múltiplos tipos de usuários com os mais diferentes tipos de interface.
3.1) Aplicações monolíticas
Na época dos computadores de 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. Pode-se definir este tipo de aplicação como aplicação de uma camada ou monolítica , esquematizada a seguir:
3.2) 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.
3.3) 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.
4) Solução
O paradigma da orientação a objetos tem tido um grande avanço nestes últimos tempos. 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 está 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.Uma possível constitui o uso do padrão (arquitetura) MVC, que permite separar as funcionalidades de modelo de negócios, da apresentação e da lógica de controle. Tal separação permite que múltiplas visões compartilhem o mesmo modelo de dados, tornado mais simples o seu desenvolvimento e manutenção.
4.1) Modelo:
Representa os dados e as regras de negócio que governam o acesso e as atualizações desses dados. O modelo é uma aproximação, simulada por software, de processos/estruturas do mundo real.
4.2) Visão:
Renderiza o conteúdo do modelo. Acessa os dados através do modelo e especifica com o dado deve ser apresentado.Mantém a consistência entre a apresentação do dado quando o modelo sofre uma mudança.
4.3) Controle
Traduz as interações dos usuários com as visões em ações a serem executadas pelos modelos. As ações a serem executadas pelos modelos incluem, por exemplo: a ativação de um processo de negócios, a mudança de estado de um modelo. Baseado na interação com usuário e nas ações decorrentes no modelo o controle responde, selecionando uma visão apropriada.
5) Conseqüências
Reuso de componentes de modelo: a separação do modelo em relação as visões permite que múltiplas visões utilizem o mesmo modelo. Os componentes do modelo da aplicação tornam-se mais simples de serem implementados, testados e mantidos, desde que todos os acessos ao modelo seja feito através desses componentes. Suporte a novos tipos de clientes: quando se tornar necessário um acesso a aplicação por um novo tipo de cliente, constrói-se uma nova visão e alguma lógica de controle nova sem que o modelo tenha que ser alterado. Aumento na complexidade do projeto: o padrão MVC introduz algumas classes adicionais para permitir a separação do modelo, das visões e controle.
6) Links Intereressantes:
Java BluePrints - J2EE Patterns
Design Patterns: Model-View-Controller
Linha de Código - Introdução a Design Patterns
Padrões de Projeto : O modelo MVC - Model View Controller
(ootips) Model-View-Controller
Nenhum comentário:
Postar um comentário