Artigos Delphi Curso de dbExpress e DataSnap - Parte XXI

Curso de dbExpress e DataSnap

Parte XXI – Servidores de Aplicação e Remote Data Modules

Utilizamos o DataModule para separar o código de acesso a dados da interface de usuário. É no DM que utilizamos os TDataSets, como a TSQLQuery e a TSQLTable, além do componente TSQLConnection. Esses componentes são responsáveis pela comunicação com o banco de dados (SGBDR). No DM geralmente também são implementados procedures que fazem validação sobre alguns dados, introduzem um campo padrão ou um campo calculado. Quando compilamos nossa aplicação, todo o código de acesso, cálculos e regras ficarão residentes em nosso executável. Se por algum motivo for necessário mudar algum parâmetro de consulta, alguma instrução SQL, um campo TField, uma máscara, alguma regra de dados, precisaremos recompilar toda a aplicação. E isso não é tudo: os componentes dbExpress usam bibliotecas .dll que devem ser colocadas em todas as máquinas da rede que acessar o banco. Também devemos instalar e configurar os conhecidos SQL Clients (clientes de banco SQL), que são bibliotecas específicas para cada SGBDR. Uma solução é separar o acesso em um Remote DataModule.

 

O Remote DataModule nada mais é do que um servidor COM, que basicamente tem a mesma função de um DM, porém pode fazer uso dos recursos do DCOM. A grande vantagem de se usar um RDM é que ele pode ficar totalmente separado do executável principal da aplicação cliente, residindo em um outro processo, em um outro computador. Surge então mais uma camada em nosso sistema. Temos aí o que se chama de uma aplicação 3 camadas : o cliente, o RDM (constituindo o servidor de aplicação) e o servidor de dados (SGBDR). As aplicações desenvolvidas utilizando esse tipo de tecnologia também são conhecidas como aplicações MultiTier (Multicamadas).

 

image001.png 

 

Figura1. Remote DataModule

Aqueles procedures que colocamos em nosso antigo DM agora serão implementados dentro de nosso servidor DCOM (o RDM). O cliente conhecendo a interface do nosso objeto DCOM pode então fazer chamadas a esses procedimentos residentes no RDM, através de uma RPC (Remote Procedure Call) usada pelo DCOM. O mecanismo que possibilita que clientes façam chamadas a funções de objetos residindo em um diferente processo ou em uma diferente máquina se chama marshaling.

O RDM será responsável por gerenciar o acesso aos dados e as regras de negócio – chamadas Business Rules (todas as validações, imposições, cálculos, constraints e acessos que envolvem os dados de uma aplicação). Os componentes de acesso do Delphi (BDE, ADO ou IBX) precisam estar somente no servidor de aplicação.

 

As bibliotecas de clientes SQL também não serão necessárias em cada máquina cliente, somente no servidor de aplicação. O cliente só precisa levar consigo a biblioteca dbclient.dll se for feito em Delphi 4 e Midas.dll se feito em Delphi 5 ou superior. Todas as aplicações clientes acessam a mesma camada (middle- tier), evitando redundância de regras de negócio, que ficam encapsuladas em uma única camada compartilhada. As aplicações clientes então contém não muito mais do que a interface com o usuário. Para o usuário final uma aplicação MultiTier não é muito diferente de uma aplicação tradicional cliente-servidor. Os clientes passam a fazer apenas alguma manipulação de tela e alguma chamadas ao servidor de aplicação (por esse motivo são chamados Thin Clients). Os clientes NUNCA se comunicam diretamente com o servidor de banco de dados.

Criando um Servidor de Aplicação DCOM

Comece uma nova aplicação em Delphi clicando em File|New|Application. Salve a unit com o nome de “uFrmMain.pas” e o projeto como “AppServerDCOM.dpr”. Dê o nome de “FrmMain” ao formulário, caption de “Servidor DCOM Ativado” e reduza o seu tamanho. Coloque-o no canto inferior direito da tela. Este formulário apenas indicará que o servidor DCOM está ativado.

 

image003.png 

Figura. Formulário principal do servidor DCOM

Agora clique em File|New|Other. No Object Repository, na guia MultiTier, escolha Remote DataModule.

 

image005.png 

Figura. Criando um Remote DataModule

Na caixa de diálogo que aparece, digite “RDM” para o nome da Co-Class. Deixe as opções Instancing e Threading Model como estão (estas são as mesmas opções disponíveis quando criamos um objeto COM no primeiro exemplo). Salve a unit criada como “uRDM.pas”.

Coloque um componente SQLConnection e configure o acesso ao banco EMPLOYEE.GDB do Interbase, normalmente situado em “C:\Arquivos de programas\Arquivos Comuns\Borland Shared\data\employee.gdb”. Defina seu LoginPrompt como False e Connected como True.

 

image007.png 

Figura. Conectando ao Interbase a partir do Remote DataModule

Coloque um SQLDataSet apontando para o SQLConnection e na sua propriedade CommandText digite:

 

select * from CUSTOMER

 

Coloque no RDM o componente TDataSetProvider (paleta DataAccess). Aponte sua propriedade DataSet para SQLDataSet. Você deve usar um componente TDataSetProvider para cada TDataSet que utilizar no RDM.

Vamos também incluir um procedure em nosso servidor, que será chamado remotamente pelo cliente, que terá a função de verificar se um determinado CPF é válido (note que a validação - uma regra de negócio - ficará totalmente separada do cliente, e se ela mudar, não precisaremos recompilar ou reinstalar clientes, além do processamento de cálculo da regra ser totalmente feito no servidor de aplicação). Importante: não confunda isso com um Stored Procedure dos servidores SQL que é algo totalmente diferente.

Abra o editor da Type Library clicando em View|Type Library. Dê um clique de direita no editor e escolha New|Method. Dê ao método o nome de VerificaCPF. Clique na guia Parameters e adicione um parâmetro chamado CPF do tipo WideString.

 

image009.png 

Figura. Criando um método no editor da Type Library

Abra a unit uRDM e localize a declaração da função VerificaCPF. Implemente a função da seguinte forma:

 

procedure TRDM.VerificaCPF(const CPF: WideString);

var

  d1,d2,n1,n2,na,loop : integer;

begin

  na:=1;

  for loop:=1 to Length(CPF)-2 do

  begin

     n1:=n1+(11-na)*StrToInt(CPF[loop]);

     n2:=n2+(12-na)*StrToInt(CPF[loop]);

     na:=na+1;

  end;

  d1:=0;

  if (n1 mod 11)>=2 then

      d1:=11-(n1 mod 11);

  d2:=0;

  n2:=n2+2*d1;

  if (n2 mod 11)>=2 then

      d2:=11-(n2 mod 11);

  if (inttostr(d1)<>CPF[10]) or

     (inttostr(d2)<>CPF[11]) then

      raise Exception.Create('CPF Inválido');

end; 

 

Pressione F9 para compilar, registrar e executar o servidor DCOM. Na próxima parte deste curso construiremos a aplicação cliente.

  

Leia todos artigos da série