Falando em Camadas

(Walter Itamar Mouro 10/98)

Nos sistemas cliente/servidor tradicionais (ou duas camadas) temos trs opes com relao s regras de negcio: colocamos junto da interface do usurio, junto do banco de dados ou mesclamos as duas opes. Nenhuma dessas opes 100 % boa. Regras junto da interface Esse caso o mais comum e somos praticamente induzidos a trabalhar assim pelas ferramentas RAD atuais, inclusive o Delphi. A possibilidade de se ligar um componente visual (TDBEdit) diretamente a um campo de uma tabela em um banco de dados (TTable), excelente no que diz respeito velocidade de programao e apresentao de resultados. Essa uma tcnica muito boa para prototipao e desenvolvimento de pequenos sistemas, mas traz incomodos enormes quando de trata de sistemas de grande porte. Entre os maiores problemas que essa forma de programar acarreta esto: Dificuldades de manuteno quando trabalhamos com os eventos de componentes visuais fcil dispersarmos as regras, tais como associarmos consistncia de campo ao evento OnExit do TDBEdit em um momento e ao OnValidate do TField em outro momento. Obviamente isso causa dores de cabea no momento da manuteno, e compulso ao suicdio caso a manuteno seja feita por outro programador. Problemas de performance (aplicao, banco e rede) pblico e notrio que a viso das tabelas de um banco de dados relacional de forma flat, mimetizando um banco no relacional causa, por si s, um impacto considervel no banco de dados e na rede como um todo, devido ao grande nmero de comandos executados e dados retornados. De fato, basta montarmos uma pequena aplicao, com um TDBGrid ligado a uma tabela no InterBase, por exemplo, e observarmos o log gerado pelo SQL Monitor aps algumas inseres e edies, assustador ! Replicao das regras todas as aplicaes que atualizam os dados de uma determinada tabela tero que replicar as mesmas regras e restries que se aplicam a esta tabela. Dificuldade de distribuio sempre que uma regra alterada o programa tem que ser redistribudo , trazendo problemas de controle de verso e distribuio fsica do aplicativo e seus complementos.

Como exemplo desse ltimo item, imagine um ambiente com 300 usurios. Acabamos de desenvolver uma aplicao que vai ser distribuda para esses 300 usurios (com BDE e etc.). Aps uma 2 semanas de instalaes descobrimos um erro grave no cdigo que nos obriga a redistribuir tudo. Mais duas semanas e lanada uma nova verso do BDE ou do transporte nativo do banco que melhora a performance de nossa aplicao consideravelmente... Enfim, podemos cair em situaes to inadimissveis quanto inevitveis.

Regras junto dos dados Ao colocarmos as regras dentro do banco de dados, usando os recursos nativos do banco de dados (triggers, stored procedures e constraints), estamos automaticamente ligando nossa aplicao ao banco de dados que estiver sendo usado, aumentando muito o retrabalho caso a aplicao venha a ser convertida para ser usada com outro banco de dados. Tipicamente isso no um problema considervel para a maioria das empresas, uma vez que a mudana de um banco de dados um operao complexa por si s, e que no pode ocorrer frequentemente. No entanto, praticamente toda software house que desenvolve em ambiente cliente/servidor enfrenta esse problema em maior ou menor grau, dependendo da complexidade e da forma de projetar os programas. Ainda em relao a essa forma de programar, pesa o estigma das restries impostas pelas linguagens nativas dos bancos, que geralmente so direcionadas e otimizadas para a manipulao de dados, e no para situaes genricas e algoritmos complexos, obrigando o programador a costurar para superar as deficincias, em particular no que se refere depurao do cdigo e tratamento de excees. Como pontos positivos restam as questes relativas ao ganho de performance na manipulao dos dados e a centralizao do cdigo que facilita a atualizao aps a manuteno, e garante a segurana do modelo de dados. Parte das regras na interface e parte junto dos dados Este o modelo mais facilmente encontrado atualmente e uma tendncia natural. Quando bem aplicado um modelo eficaz e pode atender a vrias situaes e ambientes. No entanto carrega os estigmas da dificuldade de manuteno, dificuldade de distribuio e falta de portabilidade.

3 camadas
Quando falamos em desenvolvimento em 3 camadas, estamos nos referindo a um modelo de programao que prev a diviso do programa em 3 partes bem definidas e distintas: interface, regras de negcio e banco dos dados. Nossa primeira preocupao quando estamos desenvolvendo com essa viso deve ser uma preocupao constante com a expresso bem definidas e distintas. A diviso e no intromisso de uma camada na outra a pedra fundamental desse modelo. Apesar de vrios autores usarem outras expresses tais como n-camadas e multicamadas, prefiro a expresso 3 camadas, por estarmos nos referindo s camadas lgicas da aplicao. Podemos de fato subdividir as camadas lgicas em n camadas fsicas, no entanto considero isso quase sempre irrelevante a nvel de projeto de programa.

A interface com o usurio A primeira regra na construo da interface deve ser a economia e simplicidade de cdigo. A necessidade de manuteno de um programa diretamente proporcional sua complexidade, portanto devemos sempre nos preocupar em desenvolver interfaces simples e estveis, j que essa a parte do programa que deve ser distribuda para os usurios. Essa camada tambm conhecida como camada cliente. S para lembrar: essa camada no necessita do BDE/SQL Links, facilitando muito o processo de instalao. Regras de negcio Essa camda tem a funo de servir a camada cliente, executando processos em funo de suas requisies. A inteligncia do sistema deve se concentrar nessa camada, sendo que todo e qualquer acesso aos dados deve ser feito por essa camada. Banco de dados Dentro da filosofia de desenvolvimento 3 camadas, deve-se utilizar o banco de dados como um repositrio, evitando-se a utilizao de triggers e stored procedures com o objetivo de evitar a disperso do cdigo das regras e aumentar a portabilidade. Alguns projetistas chegam a evitar completamente a utilizao de constraints no banco, conseguindo um alto grau de portabilidade. MIDAS No ambiente do Delphi, o MIDAS ( ? ) o que cola as partes, possibilitando a comunicao entre elas. Assim como tudo no Delphi, o MIDAS foi feito com o cuidado de encapsular os detalhes, deixando o programador se preocupar com questes mais relevantes para o desenvolvimento da aplicao. O MIDAS est presente no lado cliente (interface) nos componentes de conexo (TDCOMConnection, TsocketConnection, etc), e no lado servidor (regras de negcio) exercendo o papel de mediador entre a aplicao e o meio de transporte dos dados. Uma das grandes vantagens do MIDAS que o desenvolvimento da aplicao totalmente independente do tranporte, podendo inclusive mudar de transporte sem (ou quase sem) alteraes no cdigo fonte. Transporte dos dados O transporte dos dados entre as camadas pode ser feito por um entre vrios mecanismos, cada um com suas vantagens e desvantagens. O MIDAS pode ser usado com os seguintes mecanismos: COM/DCOM, CORBA, OleEnterprise e Socket. COM/DCOM O COM (Component Object Model) e o DCOM (Distributed COM) so os mecanismos desenvolvidos pela Microsoft para o ambiente Windows. A diferena entre eles que o COM o padro de comunicao entre processos rodando na mesma mquina, enquanto que o DCOM permite a comunicao entre programas que esto sendo executados em mquinas distintas. De fato o MIDAS faz uso de vrias

caractersticas do COM, mesmo quando usando outros mtodos. O DCOM nativo no ambientes Windows NT/98, enquanto que alguns arquivos adicionais so necessrios para sua utilizao no Windows 95. O COM base de toda a implementao de ActiveX encontrada no ambiente Windows, e basicamente o mesmo do OLE 1, presente no Windows 3.1. CORBA Mais que um mecanismo o CORBA (Common Object Request Broker Arquiteture) um padro desenvolvido pelo (?????) para comunicao entre processos. Atualmente o mecanismo mais maduro e completo, e sua principal implementao o Visibroker, que acompanha o Delphi nas verses Client/Server e Enterprise. um mecanismo altamente escalvel, indicado para ambientes de mdio e grande porte. OleEnterprise Apesar de ainda ser suportado, aparentemente o OleEnterprise est fadado a no ser usado. Foi desenvolvido pela (???) e baseado no COM. Socket A Inprise desenvolveu um mecanismo simples e muito prtico ser usado com o Delphi, baseado no Winsock 2.0. Muito indicado para ambientes de pequeno e mdio porte.
Interface com o Usurio MIDAS Transporte Regras de Negcio MIDAS Transporte BDE Driver BD Banco de Dados

Fig.1.1 Diagrama Geral da aplicao 3 camadas