Transporte de dados em multicamadas e DataSnap

Saiba como enviar e receber dados das aplicações Cliente e Servidora

 

Há pouco tempo atrás na empresa onde atualmente trabalho, foi necessário criar um determinado cadastro que ao ser alimentado gerava ocorrências em outras tabelas que não tinham relação nenhuma entre si. Nesta situação eram necessários alguns cálculos complexos e algumas outras validações antes de concluir este processo. Em um ambiente cliente-servidor eu poderia muito bem utilizar algumas triggers, realizar algumas pequenas adaptações e todo este problema estaria resolvido facilmente, centralizando assim todas as ações no meu banco de dados.

Porém, uma das opções de quem privilegia a utilização da arquitetura N-Tier, é optar pela carga realizada no servidor de aplicação e utilizar o banco de dados com o mínimo de objetos possíveis dentro de si. Desta forma, qualquer futura migração para outro banco de dados poderá ser realizada sem que haja grandes dores de cabeça.

Para quem já trabalha neste ambiente, certamente está acostumado a trafegar dados pela rede utilizando o DataSnap. Para isso, geralmente criamos métodos no servidor de aplicação e de alguma forma, passamos algum parâmetro necessário para sua alimentação. Porém, existem maneiras de se trafegar dados pela rede aproveitando os recursos presentes na tecnologia DataSnap, permitidas através das interações entre os eventos dos componentes ClientDataSet e DataSetProvider. Neste artigo, veremos como utilizar alguns destes eventos para realizar diversas tarefas que podem agilizar os processos de atualização de dados, inclusões, obtenção de informações do servidor de aplicação, entre outras tantas possibilidades

 

Compreendo a interatividade entre os componentes

O interessante da tecnologia DataSnap é justamente a comunicação e a interatividade entre o ClientDataSet e o DataSetProvider. Se repararmos nos eventos dos dois componentes, veremos que uma boa parte dos eventos do ClientDataSet também estão presentes no DataSetProvider. O que acontece é que inicialmente os eventos são chamados na aplicação Cliente (onde fica o ClientDataSet), que encarrega-se de gerar a requisição ao servidor. Já no servidor (onde fica o DataSetProvider), os dados são recebidos e todo o processo de atualização, validação e persistência é realizado. O resultado, que pode ser um evento de erro ou alguma informação extra, é retornado à aplicação solicitante (Cliente). Todo este processo é detalhado na Figura 1.

 

Figura 1. Conectividade entre ClientDataSet e DataSetProvider

 

Criando o banco de dados de exemplo

Para o presente modelo, pretendo apresentar um banco de dados com apenas duas tabelas que não possuem interatividade nenhuma entre si. Em nosso exemplo utilizarei o banco de dados Firebird em sua versão 1.5, porém, este exemplo é perfeitamente aplicável a qualquer outro banco de dados ou versão de sua preferência.

Conforme podemos ver na Figura 2, apenas temos a tabela CLIENTE, com informações simples sobre o cliente e a tabela LOG que possui apenas o código sequencial (ID) juntamente com o campo descritivo da ação (LOG). Perceba também que estas não possuem absolutamente nenhum relacionamento entre si. O script para a criação do banco de dados de exemplo está descrito conforme mostrado na Listagem 1.

 

Figura 2. Modelagem do banco de dados

 

Listagem 1.  Script do banco de dados

SET SQL DIALECT 3;

SET NAMES WIN1252;

 

SET CLIENTLIB '<DIRETÓRIO DA INSTALAÇÃO DO FIREBIRD>\BIN\fbclient.dll';

 

CREATE DATABASE '<DIRETÓRIO DO BANCO DE DADOS>\EXEMPLO.FDB'

USER 'SYSDBA' PASSWORD 'masterkey'

PAGE_SIZE 4096

DEFAULT CHARACTER SET WIN1252;

 

CREATE TABLE CLIENTE (

    IDCLIENTE   INTEGER NOT NULL,

    CLIENTE     VARCHAR(100) NOT NULL,

    ENDERECO    VARCHAR(100),

    BAIRRO      VARCHAR(100),

    CIDADE      VARCHAR(100),

    ESTADO      CHAR(2),

    CEP         CHAR(8),

    TELEFONE    VARCHAR(10),

    OBSERVACAO  VARCHAR(1000)

);

 

ALTER TABLE CLIENTE ADD CONSTRAINT

PK_IDCLIENTE PRIMARY KEY (IDCLIENTE)

USING INDEX IDX_CLIENTE;

 

CREATE TABLE LOG (

    IDLOG  INTEGER NOT NULL,

    LOG    VARCHAR(100)

);

 

ALTER TABLE LOG ADD CONSTRAINT PK_IDLOG PRIMARY KEY (IDLOG)

USING INDEX IDX_IDLOG;

 

CREATE GENERATOR GEN_IDCLIENTE;

CREATE GENERATOR GEN_IDLOG;

 

...
Quer ler esse conteúdo completo? Tenha acesso completo