APLICAÇÔES 3 CAMADAS

EDILSON DUARTE NETO

Desenvolvimento de Aplicaçôes 3 Camadas

Edilson Duarte Neto(Faculdade Christus) edilsondneto@yahoo.com.br

Resumo

Desenvolvimento em 3 camadas: estas aplicações provêem uma divisão entre as seguintes camadas: camada de apresentação (interface gráfica na máquina do usuário), camada de negócios (reside em localização central acessível a todos clientes, fornecendo serviços comuns de dados) e e camada de acesso a dados (fornece o sistema de gerência de banco de dados relacional).

Abstract

Development in 3 layers: these applications to provide a division between the following layers: business-oriented layer of presentation (graphical interface in the machine of the user), layer (it inhabits in accessible central localization to all customers, supplying common services of data) and layer of access the data (it supplies the system of management of relationary data base).

Palavras-chave - Camadas; Visualização; Negocio; Persistência.

Keywords - Layers; Visualization; Negotiate; Persistence.

  1. INTRODUÇÃO

Essa forma ampla de desenvolvimento em 3 camadas que pode ser aplicada com varias linguagens de programação e em diferente bancos de dados. Vejamos as distinções das camadas de uma forma ampla sem nenhum relacionamento a linguagem a ser aplicada, vejamos:

1.1 - Visualização

A interface com o usuário - A primeira regra na construção da interface deve ser a economia e simplicidade de código. A necessidade de manutenção de um programa é diretamente proporcional à sua complexidade, portanto devemos sempre nos preocupar em desenvolver interfaces simples e estáveis, já que essa é a parte do programa que deve ser distribuída para os usuários. Essa camada também é conhecida como camada cliente é responsável pela formatação das telas que são apresentadas aos usuários.

1.2 - Regras de negócio

Essa camada tem a função de servir a camada cliente, executando processos em função de suas requisições. A “inteligência” do sistema deve se concentrar nessa camada, sendo que todo e qualquer acesso aos dados deve ser feito por essa camada é responsável por manter o estado e a lógica da aplicação. Controla o processamento das ações requeridas pelo usuário, aplica segurança através de identificação do usuário e aciona operações no banco de dados, retornando o conteúdo que será enviado a camada de visualização e utilizado pelo cliente

1.3 - Banco de dados

Deve-se utilizar o banco de dados como um repositório, evitando-se a utilização de triggers e stored procedures com o objetivo de evitar a dispersão do código das regras e aumentar a portabilidade. Alguns projetistas chegam a evitar completamente a utilização de constraints no banco, conseguindo um alto grau de portabilidade.

  1. Utilização do Modelo em 3 camadas em diferentes linguagens.

2.1 Ambiente Delphi 7 Utilizando Tecnologia Midas.

2.1.1 - Midas

No ambiente do Delphi, o MIDAS é o que “cola” as partes, possibilitando a comunicação entre elas. Assim como tudo no Delphi, o MIDAS foi feito com o cuidado de encapsular os detalhes, deixando o programador se preocupar com questões mais relevantes para o desenvolvimento da aplicação. O MIDAS está presente no lado cliente (interface) nos componentes de conexão (TDCOMConnection, TsocketConnection, etc), e no lado servidor (regras de negócio) exercendo o papel de mediador entre a aplicação e o meio de transporte dos dados. A arquitetura MIDAS tem o seu foco no desenvolvimento de aplicções de três camadas. A idéia deste modelo é permitir maior independência entre as camadas. Na camada de apresentação pode-se optar em utilizar uma aplicação normal e também pode-se optar por trabalhar com uma aplicação mais leve, que funcione através de um navegador como o Internet Explorer ou o Netscape Navigator. Para isto se usa os componentes Internet Express, que irão trabalhar com tecnologia XML e o middleware escolhido (DCOM ou HTTP, por exemplo). Na camada do meio armazenadas as regras de negócio. Ainda, esta camada é responsável por realizar a comunicação entre a aplicação cliente (interface com o usuário) e a base de dados fazendo validações de dados comuns. A camada do meio também fica conhecida como o "servidor de aplicação", é o aplicativo responsável por intermediar o fluxo de informações entre o aplicativo cliente e o SGBD. Qualquer manutenção necessária com relação as regras de negócio nos sistemas que utilizam esta tecnologia ficam restritas a apenas 1 local, no caso, o servidor de aplicação, o que vai com certeza facilitar a manutenção dos Sistemas. Outra informação relevante é que a máquina cliente não possui nenhuma ferramenta de acesso a dados. Todo o controle de acesso a dados fica na camada intermediária, o servidor de aplicação tem esta função. No lado cliente no momento da implantação do sistema uma DLL deve ser instalada, a DBCLIENT.DLL. O Borland Database Engine (BDE) se for utilizado no acesso a dados, fica então instalado apenas no servidor de aplicação.

Transporte dos dados

O transporte dos dados entre as camadas pode ser feito por um entre vários mecanismos, cada um com suas vantagens e desvantagens. O MIDAS pode ser usado com os seguintes mecanismos: COM1/DCOM, CORBA², OleEnterprise e Socket.

COM / DCOM – O COM (Component Object Model) e o DCOM (Distributed COM) são os mecanismos desenvolvidos pela Microsoft para o ambiente Windows. A diferença entre eles é que o COM é o padrão de comunicação entre processos rodando na mesma máquina, enquanto que o DCOM permite a comunicação entre programas que estão sendo executados em máquinas distintas. De fato o MIDAS faz uso de várias características do COM, mesmo quando usando outros métodos. O DCOM é nativo no ambientes Windows NT/98, enquanto que alguns arquivos adicionais são necessários para sua utilização no Windows 95.

CORBA – Mais que um mecanismo o CORBA (Common Object Request Broker Arquiteture) é um padrão para comunicação entre processos, isso é essa arquitetura que permite que partes de programas, chamados objetos, se comuniquem com outros não importando a linguagem de programação na qual eles tenham sido escritos. Atualmente é dos mecanismos mais maduro e completo, e sua principal implementação é o Visibroker, que acompanha o Delphi nas versões Client/Server e Enterprise. É um mecanismo altamente escalável, indicado para ambientes de médio e grande porte.

OleEnterprise – Apesar de ainda ser suportado, aparentemente o OleEnterprise está fadado a não ser usado e é baseado no COM.

Socket – A Inprise desenvolveu um mecanismo simples e muito prático ser usado com o Delphi, baseado no Winsock 2.0. Muito indicado para ambientes de pequeno e médio porte, os sockets permitem que uma aplicação se comunique com outras aplicações através da rede. Estes provêem uma solução de baixo nível e de propósito geral para comunicação interprocessos. Para um programa de propósito geral em que se deseja utilizar sockets, o programador deve implementar o protocolo que vai funcionar como a comunicação entre um "cliente" e um "servidor". Também é possível se implementar aplicações usando MIDAS e conexões de sockets. O funcionamento das aplicações é o seguinte: uma instância da classe TSocketConnection (componente responsável por estabelecer a comunicação entre cliente e servidor de aplicação) estabelece uma comunicação inicial entre o cliente e o servidor de aplicação usando TCP/IP. Um requisito aqui necessário é que o servidor esteja executando uma aplicação chamada ScktSrvr.exe.

Fig.1 – Diagrama Geral da aplicação 3 camadas em Delphi

2.2 Ambiente Ruby Utilizando Rails.

2.2.1 - Arquitetura do Rails

Rails é um framework de desenvolvimento web baseado no padrão MVC. Ele gera uma estrutura para o desenvolvimento de aplicações web, onde o desenvolvedor produz os modelos, as interfaces e os controladores como um conjunto de funcionalidades separadas, cada um no seu lugar específico, e através da convenção de nomenclatura ele integra todo esse conjunto quando a aplicação é executada. Em aplicações desenvolvidas em Rails, as requisições são primeiro enviadas para um roteador que decide para onde, na aplicação, deve ser enviada e como ela deve ser quebrada. Por último, essa fase identifica um método específico, chamado de Action no Rails, em algum lugar no código do controlador. A action então deve olhar para os dados da requisição, interagir com a camada de modelo, e então invocar outras actions ou pode preparar informação para ser entregue para a camada de Visualização, que então apresenta essas informações para os usuários. Na figura a seguir temos o comportamento do Rails para o recebimento de uma chamada. Esta chamada apresenta a URL http://my.url/store/add_to_cart/123, nesta URL, através das convenções de nomenclatura identifica que a requisição deve ser processada pelo método add_to_cart do controlador store. O valor 123 é identificado como o id do produto a ser adicionado ao carrinho.

Fig 2 - MVC no Rails (THOMAS, HANSSON, 2005)

A utilização do padrão MVC no Rails vai além da montagem da arquitetura para a aplicação.

O Rails possui um conjunto de padrões que dão suporte as três camadas.

Na camada de modelo, o Rails utiliza o ORM (Object/Relational Mapping), que é o mapeamento das classes de objetos para as tabelas de banco de dados. Esse padrão é utilizado por outros frameworks para outras linguagens. O que diferencia o Rails dos outros frameworks, é o fato de que o Rails não utiliza nenhum arquivo de configuração para estabelecer esse relacionamento. Ele utiliza Active Record, que é o ORM suportado pelo Rails, que realiza o mapeamento através de suas convenções, além de possuir alguns padrões iniciais. O uso do Active Record facilita muito o desenvolvimento, visto que o mapeamento realizado por arquivos de configurações, são, por muitas vezes, complexos, grandes e precisam ser alterados sempre que acontecer uma modificação no objeto. Com isso, projetos em Rails têm a sua manutenção simplificada.

Semelhanças das camadas: Visualização e Controle

Nas camadas de controle e visualização, o framework possui um único componente de suporte. Isso se deve ao fato de que essas duas camadas estão estritamente ligadas, uma vez que o controlador é responsável por gerar as informações que serão apresentadas na camada de vista e recebe desta os eventos de respostas das páginas web. Apesar do Rails fazer uso de apenas um componente para as duas camadas, não significa que os códigos para essas serão misturados ou guardados em um único lugar. Pelo contrário, os códigos são bem divididos e esse componente é que fica responsável pelo transporte das informações entre as duas de maneira simples.

No Rails, a camada de visualização é responsável pela criação de toda ou parte da página a ser exibida no navegador. Muitas vezes essas páginas apresentam conteúdo dinâmico. O Rails possui duas formas de inclusão desses conteúdos nas páginas: uma é a utilização de código Ruby, embutido nas páginas HTML através de tags específicas do Rails, e a outra é através de builder-style views, onde são usados arquivos XML, com código em Ruby.

A camada de controle (controlador) no Rails é o centro lógico de sua aplicação. Ele é o responsável pela interação entre o usuário, a camada de visualização e a camada do modelo. Muitas dessas interações são transparentes ao desenvolvedor, pois são feitas através das convenções do framework, possibilitando que o desenvolvedor se concentre nas funcionalidades, no nível da aplicação, o que torna os código muito simples, fáceis de serem desenvolvidos e de sofrerem manutenção. O controlador é, também, o lugar de um numero de serviços importantes. (THOMAS HANSSON, 2005). É responsável pelo roteamento de requisições externas para ações internas. Isso sustenta roteamento de requisições externas para ações URLs amigáveis aos usuários. Gerencia o cache, que pode dar um ganho de performance de aplicações com grande número de requisições. Gerencia módulos de ajuda, que estendem as capacidades dos templates da camada de visualização a sem dificultar os seus códigos. Gerencia as sessões, dando aos usuários a impressão de uma interação contínua com as aplicações.

3 -Vantagens de se usar o modelo 3 camadas temos:

3.1 -Encapsulamento da lógica de negócios em um nível intermediário compartilhado: todos os clientes acessam os mesmos objetos de negócio, que estão em uma localização centralizada (podem estar replicados). Isto facilita a redundância e a manutenção das aplicações clientes;

3.2 - Aplicações clientes menores: aplicações ficam menores e mais genéricas, por delegarem o processamento aos níveis intermediários. Também são mais fáceis de serem distribuídas, pois não é necessário se preocupar com o software que faz o acesso aos dados, já que o acesso a dados é realizado pelo nível intermediário;

3.3 - Processamento distribuído dos dados: distribuindo o serviço da aplicação entre diversas máquinas pode melhorar o desempenho graças a equalização de carga, onde as requisições podem ser gerenciadas pelos diversos servidores de aplicação existentes e ainda permite que um dado servidor de aplicação saia do ar, sem prejudicar o funcionamento do sistema, pois o servidor de aplicação vai estar replicado em outras máquinas servidoras;

3.4 - Capacidade de segurança aumentada: é possível isolar funcionalidades sensíveis em camadas com diferentes restrições de acesso. Isto provê níveis de segurança mais flexíveis e configuráveis. As camadas intermediárias podem limitar os pontos de entrada para determinadas funcionalidades, facilitando o controle.

4. Conclusão

O modelo MVC (3 camadas) de arquitetura de aplicativos permite a separação das camadas de dados, controle e visualização. Esta separação oferece vantagens para desenvolvedores como a otimização das habilidades de equipes e a redução de custos associados ao desenvolvimento, além de favorecer a extensibilidade e reutilização do código. Aplicativos Desktops escritos em Delphi podem implementar MVC, sendo que Ruby on Rails oferece maior gama de possibilidades de utilização e maior facilidade dessa forma implementação.Empresas que não utilizarem o modelo MVC no desenvolvimento de aplicativos estarão restringindo seus projetos aos requisitos atuais e correrão o risco de inviabilizar futuras atualizações ou mesmo de isolamento por restrição à integração com outros projetos..

Referências Bibliográficas

AKITA, Fábio, Repensando WED com Rials. 1 ed. Brasport, 2006.

WILDT, Daniel de Freitas, Programação Distribuída no Ambiente Delphi 5 utilizando tecnologia MIDAS - Disponível em: http://www.inf.ufrgs.br/~wildt/cmp167/t1/cmp167_t1 wildt.htm. Acesso em: 27 out. 2007.

Almost All Java Web Apps Need Model 2. The design model you first learned with JSP might not scale or support complexity. by Budi Kurniawan http://www.fawcette.com/javapro /2002_06/online/servlets_06_11_02/

MOURÃO . Walter Itamar, Falando em camadas. Developers Magazine, 01 out. 1998.Referências adicionais: Brasil/Português; Meio de divulgação: Impresso; Data de publicação: 01/10/1998.

1 COM é base de toda a implementação de ActiveX encontrada no ambiente Windows, e é basicamente o mesmo do OLE 1, presente no Windows 3.1.

2.Corba foi desenvolvida por um consórcio de indústrias conhecido como Object Management Group (OMG)

Comentários