Artigos Delphi QUICK TIPS: Data Module - Como administrar sua utilização em projetos Delphi - PARTE I
 

Olá para todos os leitores da DevMedia, meu nome é Ricardo Oliveira e estive afastado durante alguns anos da área de análise e desenvolvimento de sistemas por estar fora do escopo profissional das empresas que prestei meus serviços. Resolvi voltar a desenvolver há alguns meses e entre a comunidade de desenvolvedores pude notar que várias aplicações Client/Server vem sendo desenvolvidas de forma meio que displicente, se assim posso dizer.

Apesar de muitas vezes não darem a devida importância na utilização do Data Module, ele fornece uma enorme praticidade na organização estrutural do seu projeto e escalabilidade (habilidade de manipular uma porção crescente de trabalho de forma uniforme, preparando assim o seu projeto para crescer). Então vamos analisar tudo isso e verificarmos a melhor abordagem na utilização deste componente tão importante na administração do seu projeto.


 

DATA MODULE (MÓDULO DE DADOS) 

  

Uma breve introdução do que é um Data Module que esta presente no Delphi desde a versão 2. Em tempo de projeto (design time), um Data Module é semelhante a um Form, mas em tempo de execução (run time) ele existe somente na memória. Imagine como se fosse um Form invisível no qual se pode incluir componentes invisíveis da VCL do Delphi.

 

 

A classe TDataModule se deriva diretamente de TComponent, esta então sem ligação ao conceito Windows de janelas (e plenamente portátil entre sistemas operacionais diferentes). Diferente do Form, o Data Module tem somente algumas propriedades e eventos, então, é certo imaginar o Data Module como um container de componentes não visuais que geralmente são utilizados em aplicações de banco de dados e web. Beleza até aqui? Então vamos lá.

 

 

Porque usar o Data Module em aplicações Client/Server

 

 A justificativa simples para o uso do Data Module em vez de simplesmente incluir componentes de acesso a dados em um Form é que, dessa forma, é mais fácil compartilhar os mesmos dados entre vários Forms (Formulários) e Units (Unidades) do seu projeto.

 

              A prática de colocar os componentes de acesso aos dados (data-access) e os controles para os mesmos (data-aware) no próprio form seria mais para um programa simples de acesso aos dados do que ter uma aplicação Client/Server com Banco de Dados. Ter a interface de usuário, os dados de acesso e o modelo de dados em uma única (frequentemente grande) unidade esta longe de ser uma boa técnica de programação.


 

              Em uma situação mais complexa, você teria uma organização de vários componentes TSQLConnection, TSQLDataSet, TDataSetProviders, TClientDataSet, TDataSource, TSQLQuery e/ou TSQLStoredProc espalhados por todo o seu projeto dentre vários Forms o que lhe traria inúmeros problemas até mesmo para dar manutenção ao seu sistema posteriormente.

 

 

              Os Data Modules permitem manter todas as suas regras e relacionamentos do banco de dados entre outros em um local central, para serem compartilhados entre projetos, grupos ou até empresas. A inclusão do Data Module no seu projeto é bem simples: selecione File, New no menu principal do Delphi e depois selecione Data Module a partir do Object Repository. 

 

                   

 

                    Figura 1 - Imagem do Data Module novo.

 

 

CONCEITO DE UTILIZAÇÃO DE UM ÚNICO DATA MODULE 

 

Ao utilizarmos esta abordagem, todos os componentes de acesso ao Banco entre outros estarião armazenados em um único Data Module, inclusive todas as regras de negócio associadas à aplicação. Essa abordagem proporciona ao desenvolvedor o 'luxo' de ter em um único compartimento todas as funcionalidades de banco de dados para gerenciar dentre outros componentes do projeto. Apesar de ser bem cômoda esta abordagem ela oferece algumas limitações. Vamos a um exemplo de aplicativo que utilize esta forma de gerenciamento.

 

 

Figura 2 - Imagem do Data Module único e com todas as regras de negócio.

 

Dica: Para quem ainda não sabia, o Data Module armazena também componentes da VCL como TMainMenu, TPopupMenu, TActionsList, TImageList, TTimer dentre vários outros. Para conhecer todos você pode selecionar na paleta do Delphi as abas de componentes com o Data Module ativo no projeto que será mostrado somente os componentes disponíveis para a inclusão no Data Module (todos não visíveis em run time).

 

Observe na figura acima que toda a funcionalidade de banco de dados e alguns componentes úteis podem ser encontrados neste Data Module único do projeto. Todos os parâmetros, atualizações, validações e outros estão armazenados no Data Module em questão nomeado de dtmdlPrincipal, porém essa vantagem de armazenarmos toda a funcionalidade do sistema em um único local pode nos trazer sérias limitações se formos analisar a instancia em memória que será utilizada, o conceito de herança e a forma que muitos programadores conduzem o sistema.

 

 

Vamos observar um exemplo que em determinado momento do sistema estaríamos interessados em consultar as informações somente do clntdtstCustomer, uma vez que o exemplo mostrado acima onde utilizamos apenas um Data Module, todos os outros componentes de acesso ao banco de dados estariam instanciados também, no entanto a necessidade seria somente da funcionalidade do clntdtstCustomer. Estamos dessa forma carregando em memória vários outros componentes de acesso ao banco de dados ocupando um espaço desnecessário.

 

 

Outro problema a ser abordado é a capacidade do Delphi de herança a partir de um Data Module. O Delphi permite esta herança como à de outros componentes, mas particularmente neste caso com um interesse em particular de suportar aplicativos multitier (que utiliza a tecnologia DataSnap). Muitos conflitos poderiam ocorrer se você futuramente adota-se no seu projeto o conceito de três níveis onde a herança é realizada a partir de um Data Module com um componente de acesso ao banco de dados (no caso o sqlcnctnMaster). Você teria duas vias de conexão com o banco de dados, uma a partir do Data Module ancestral e outra a partir do descendente do mesmo.

 

 

Finalmente ao aspecto sobre os quais muitos desenvolvedores se preocupam que seria tragicamente sacrificado, o desempenho. De acordo com essa abordagem a performance do sistema seria muito prejudicada, pois muitos desenvolvedores abrem as suas consultas quando o Data Module é instanciado (criado na memória). Obviamente acarretaria um tráfego na rede desnecessário com uma sobrecarga no servidor de banco de dados mais do que necessariamente deveria ser utilizada.

 

 

 
                 Continua: “Data Module - Como administrar sua utilização em projetos Delphi. PARTE II”.

                 Abraço a todos e até o próximo!!!