APLICAÇÔES 3 CAMADAS

EDILSON DUARTE NETO

 2

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
 3

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.

2. 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 é

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.
21.Corba foi desenvolvida por um consórcio de indústrias conhecido como Object Management Group (OMG)
 4

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.

Interface Regras de Negócio

MIDAS MIDAS BDE

Banco
Transporte Transporte Driver BD

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
 5

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
 6

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.
 7

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.