Curso de dbExpress e DataSnap - Parte XXI
Veja neste artigo de Guinther Pauli, mais um capítulo do curso de dbExpress e DataSnap. Acesso exclusivo para Assinantes.
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
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).
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.
Figura. Formulário principal do servidor DCOM
Agora clique em File|New|Other. No Object Repository, na guia MultiTier, escolha Remote DataModule.
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.
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.
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
- Curso de dbExpress e DataSnap
- Curso de dbExpress e DataSnap - Parte II
- Curso de dbExpress e DataSnap - Parte III
- Curso de dbExpress e DataSnap - Parte IV
- Curso de dbExpress e DataSnap - Parte V
- Curso de dbExpress e DataSnap - Parte VI
- Curso de dbExpress e DataSnap - Parte VII
- Curso de dbExpress e DataSnap - Parte VIII
- Curso de dbExpress e DataSnap - Parte IX
- Curso de dbExpress e DataSnap - Parte X
- Curso de dbExpress e DataSnap - Parte XI
- Curso de dbExpress e DataSnap - Parte XII
- Curso de dbExpress e DataSnap - Parte XIII
- Curso de dbExpress e DataSnap - Parte XIV
- Curso de dbExpress e DataSnap - Parte XV
- Curso de dbExpress e DataSnap - Parte XVI
- Curso de dbExpress e DataSnap - Parte XVII
- Curso de dbExpress e DataSnap - Parte XVIII
- Curso de dbExpress e DataSnap - Parte XIX
- Curso de dbExpress e DataSnap - Parte XX
- Curso de dbExpress e DataSnap - Parte XXI
- Curso de dbExpress e DataSnap - Parte XXII
- Curso de dbExpress e DataSnap - Parte XXIII
- Curso de dbExpress e DataSnap - Parte XXIV
- Curso de dbExpress e DataSnap - Parte XXV
- Curso de dbExpress e DataSnap - Parte XXVI
- Curso de dbExpress e DataSnap - Parte XXVII
- Curso de dbExpress e DataSnap - Parte XXVIII
- Curso de dbExpress e DataSnap - Parte XXIX
- Curso de dbExpress e DataSnap - Parte XXX
Artigos relacionados
-
Artigo
-
Artigo
-
Artigo
-
Artigo
-
Artigo