Aplicações monolíticas
[color=orange]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 :
[/color]
Aplicações em duas camadas
[color=violet]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.
[/color]
Aplicações em três camadas
[color=blue]
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.
[/color]
O padrão MVC
[color=green]
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.
* inclui os elementos de exibição no cliente : HTML , XML , ASP , Applets .
* É a camada de interface com o usuário.
* É usada para receber a entrada de dados e apresentar o resultado
Camada de lógica da Aplicação - É o coração da aplicação . Responsável por tudo que a aplicação vai fazer.
* modela os dados e o comportamento por atrás do processo de negócios
* se preocupa apenas com o armazenamento , manipulação e geração de dados
* É um encapsulamento de dados e de comportamento independente da apresentação.
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.
* controla e mapeia as ações
Vantagens do modelo MVC :
- Como o modelo MVC gerencia múltiplos visualizadores usando o mesmo modelo é fácil manter , testar e atualizar sistemas múltiplos
- É muito simples incluir novos clientes apenas incluindo seus visualizadores e controles
- Torna a aplicação escalável
- É possível ter desenvolvimento em paralelo para o modelo , visualizador e controle pois são independentes.
Desvantangens do modelo MVC:
- Requer uma quantidade maior de tempo para analizar e modelar o sistema
- Requer pessoal especializado
- Não é aconselhável para pequenas aplicações
[/color]
[color=darkblue] by http://www.macoratti.net/vbn_mvc.htm[/color]