Curso de dbExpress e DataSnap

Parte III - Arquitetura

Nesta parte do curso, vamos examinar detalhes sobre a arquitetura de aplicações dbExpress que utilizam os componentes básicos, típicos de uma aplicação client/server ou multicamadas: SQLConnection, SQLQuery, DataSetProvider e ClientDataSet . Veremos também as vantagens em se utilizar uma aplicação multicamadas.

Arquitetura

A figura a seguir mostra as partes envolvidas em um sistema multicamadas. Na primeira camada, temos o chamado servidor de dados. Nele está localizado o banco de dados propriamente dito. O banco de dados pode ser Oracle, DB2, MySQL, Interbase ou qualquer outro suportado pelo dbExpress. Como a conexão é feita via TCP/IP, você pode usar um SO diferente do Windows, como Linux.

A camada intermediária, conhecida como servidor de aplicação, contém o DataModule (também conhecido como RemoteDataModule ) responsável pelo acesso a dados. Nessa camada se encontram os componentes dbExpress, como SQLConnection, SQLQuery, SQLDataSet e os DataSetProviders . Nessa camada você também vai incluir as chamadas regras de negócio . Business Rules são regras impostas sobre dados, que não serão mais processadas no servidor SQL. Com isso, seu sistema consegue centralizar as regras sem depender do tipo de banco utilizado.

E finalmente, a camada cliente é responsável apenas pela apresentação dos dados. Contém basicamente regras de tratamento de tela e interface. Por isso, são chamadas de thin-clients (clientes leves).

image001.png 

A seguir, vamos examinar as vantagens de se desenvolver aplicações multicamadas com DataSnap e dbExpress.

Vantagens de uma solução Multitier

Modularização da aplicação em 3 camadas

Quando desenvolvemos uma aplicação Multicamadas com DataSnap, separamos a lógica de negócio e regras de acesso a banco de dados das regras de interface de usuário. Dessa forma, vários clientes podem compartilhar as mesmas regras, que ficam encapsuladas em uma camada de acesso comum. Observe que em uma aplicação 2 camadas há geralmente uma redundância de regra de negócio nas estações clientes, e uma simples mudança nessa regra requer uma nova distribuição da aplicação. Suponha que você esteja fazendo um simples cadastro de clientes, com interface tradicional baseada em formulários. Então você inclui no DataModule da aplicação uma determinada validação de dados. Se você agora precisar construir uma versão On-Line deste cadastro, através de um formulário que poderá ser aberto em um browser Web, então será necessário recodificar a regra anterior. Neste caso, uma camada lógica intermediária poderia centralizar todas as regras e atender tanto aplicações clientes baseadas em formulários, quanto aplicações baseadas em browser.

Clientes Leves (Thin-Clients)

Uma aplicação cliente de uma arquitetura Multitier basicamente contém código de interface. Todo o processamento das solicitações de dados ao servidor SQL são feitas na camada intermediária, de forma que um cliente nunca se comunica diretamente com o banco de dados. Dessa forma, uma aplicação cliente DataSnap é muito leve, pequena, e de configuração quase zero. Por este motivo este tipo de cliente é também conhecido como Thin-Client ou cliente leve (magro).

Economia de licenças de acesso a Banco de dados

Quando trabalhamos com aplicações 2 camadas, cada cliente de nossa aplicação se comunica diretamente com o banco de dados, por meio de um SQL Client. Este SQL Client é um conjunto de bibliotecas (que muitas vezes ocupam vários MB de espaço em disco) que possibilita um terminal da rede trocar comandos SQL com um servidor de dados SQL. Você precisa instalar estas bibliotecas em cada estação que acesse o servidor. Quando o driver do cliente troca de versão, você precisa atualizar todas as máquinas da rede (isso sem falar da sua aplicação). Um outro aspecto nada interessante é que geralmente as empresas fabricantes de banco de dados cobram licenças extras pela instalação destas bibliotecas clientes. Agora se você construir seu sistema baseado em uma arquitetura Multitier, as bibliotecas do SQL Client (seja qual for o banco) deverão ser instaladas somente na camada intermediária (camada de acesso a dados), poupando conexões no servidor e economizando licenças. Todos os clientes dessa forma compartilham uma única conexão com o banco de dados SQL. Se seu aplicativo utiliza ainda o BDE como tecnologia Borland de acesso a dados, estes drivers também serão necessário somente na aplicação intermediária, e não mais no cliente final. O mesmo vale para os drivers de acesso a dados do dbExpress.

Escalabilidade

Um software bem desenvolvido sobre uma arquitetura Multicamadas é extremamente escalável. Isto é, a medida que mais clientes começam a conectar no servidor de aplicação e utilizar seus recursos, não há uma perda de desempenho e performance, como acontece em aplicações 2 camadas tradicionais.

Independência de Linguagem

Uma camada de negócio construída sobre um padrão COM, por exemplo, pode ser acessada por clientes escritos em diversas linguagens de programação que dêem suporte ao COM. Essa comunicação é possível devido ao mecanismo conhecido como Interfaces. Um servidor COM (escrito em Delphi, por exemplo) pode ser acessado de um cliente escrito em VB, ASP, C, etc.

Independência de Banco de Dados

Como uma aplicação cliente Datasnap não se comunica diretamente com o banco de dados, este não precisa nem mesmo saber qual é o banco de dados utilizado. É possível migrar de Banco de Dados, por exemplo, de Interbase para Oracle, sem mesmo recompilar as aplicações clientes (e as vezes nem mesmo a camada intermediária).

Balanceamento de Carga

Um servidor de aplicação pode ser configurado para automaticamente distribuir as conexões clientes para outros servidores de aplicação, tornando a arquitetura ainda mais escalável. Isso é facilmente alcançado apenas se usando o componente SimpleObjectBroker.

Funcionamento de uma aplicação dbExpress

A figura a seguir mostra uma aplicação típica dbExpress, e todos os passos envolvidos desde a requisição de dados até a atualizações das alterações no servidor. Todos os procedimentos a seguir acontecem imediatamente após você dar um Open em um ClientDataSet . Incluí também a especificação das etapas de atualização.

 

Conexão: o componente SQLConnection estabelece uma conexão TCP/IP com o servidor SQL;

 

Abertura de um cursor de dados: um SQLDataSet ou SQLQuery efetua uma consulta ( select ) no banco de dados, por meio de um SQLConnection . O servidor SQL abre então um cursor de dados, alocando recursos;

 

DataSetProvider : após o cursor ser aberto, o DataSetProvider varre o cursor de dados (uma operação while not eof ) montando um pacote de dados ( DataPacket ).

 

Providing : o DataSetProvider fecha o cursor de dados, liberando recursos, e envia os dados obtidos em forma de DataPacket para o ClientDataSet , em uma operação chamada Providing .

 

Cache : o ClientDataSet armazena os dados em cache, local, não sendo necessária nenhuma conexão com o banco de dados;

 

ApplyUpdates - o ClientDataSet envia as atualizações de volta ao DataSetProvider , em um pacote de dados conhecido como Delta ;

 

Resolving – para cada registro alterado, o DataSetProvider tenta atualizar o respectivo registro no banco de dados, gerando automaticamente instruções de atualização como update, delete e insert .

 

Reconcile – eventuais erros ocorridos durante o Resolving são devolvidos ao ClientDataSet , para que sejam tomadas soluções, em um processo chamado Reconcile .

image003.png

 

Download

Você pode fazer download de todos os exemplos deste curso a partir do endereço cc.borland.com/cc/ccweb.exe/author?authorid=222668

 

dbExpress, DataSnap e ClientDataSet: técnicas avançadas

Para mais informações sobre acesso a dados no Delphi e técnicas avançadas, sugiro a leitura do meu livro, “Delphi: Programação para Banco de Dados e Web”, como apoio para o aprendizado das tecnologias. Na obra mostro várias técnicas introdutórios e avançadas de desenvolvimento com ClientDataSet, dbExpress e DataSnap (multicamadas, incluindo SOAP e COM+). Para mais informações, consulte o link https://ssl.dominal.com/clubedelphi/loja/descricao.asp?codigo=114&cod_pai=6

 

Leia todos artigos da série