Um conhecimento só é válido quando compartilhado.

domingo, 23 de abril de 2017

Mitos Sobre os TDataModules

Seja bem vindo, e ótima leitura.
Teve uma discussão sadia sobre o uso de datamodule no face postado por Savério Vertoni Jr. em cima da seguinte imagem: 
Sou do signo de gêmios, dizem que quem é de gêmios quer convencer as pessoas da sua verdade ou do que acham que é verdade, eu particularmente gosto de usar fundamentos para mostrar o que acredito ser a minha verdade, claro temos livre arbítrio para escolhermos o que achamos que é melhor para nós, isso nós chamamos de liberdade de expressão. 
Agora podemos sim expor o que achamos certo e se quisermos que alguém acredite façamos da forma concreta, mostrando o porque da opinião, e talvez ai, alguém irá vê que sua opinião tem base para ser verdade ou não. 
Nesse poste podemos ver alguns cenários para exemplificar o uso de datamodules é sobre o que visualizei que vou comentar. 
Os comentários do post foi com base em uma pratica totalmente inviável como visto na imagem acima, vou explicar porque, também teve comentários que disseram que devemos criar um datamodule por módulo de sistema, também inviável, vou explicar porque, e comentário sobre o que disse o Vertoni em cria datamodule por form, "haja memória", isso é mito, pois uso de datamodulo por form não estoura memoria, na minha opinião á a melhor maneira de se usar datamodule, vou explicar porque.

Cenário 1 - Uma datamodule único com tudo nele, como mostrado no na imagem do post é inviável porque?
 
a) Teremos que instância-lo no inicio da aplicação, isso irá sobrecarregar a abertura da app pela quantidade demaciada de componentes
b) Terá que ficar disponível enquanto a aplicação estiver aberta, pois todo mundo dependerá de usa-lo. 
c) Manutenção no fonte desse datamodule, tente visualizar o fonte com os vários eventos de cada um componente ativo, impraticável implementar, corrigir, achar algo de forma escalável, pois terá rotina que atenderá a todo mundo.

Cenário 2 - Datamodule por módulo de sistema é inviável porque? 

a)
Independente de como se organiza quais componentes colocar no datamodule de cada módulo, sempre terá nesse datamodule informações que não será usado por alguma situação, e nesse momento tenho informações na memória desnecessárias. 

b) Terá que ficar disponível sempre, pois a qualquer momento, algum form que faz parte do módulo precise acessa-lo. Agora se criar um para cada form  que precise dele, pior ainda, ai inchar a memória mesmo, cada um com um montão de coisa desnecessária. 
c) Manutenção no fonte desse datamodule, tente visualizar o fonte com os vários eventos de cada um componente ativo, impraticável implementar, corrigir, achar algo de forma escalável, pois terá rotina que atenderá a todo módulo. 

Cenário 3 - Datamodule por Form, haja memória, mito, para mim é a melhor forma a ser usada.

a)
"Haja memória" porque? Se o datamodule só deve ser criado no Create form e liberado do Destroy? Se no EXE tem 1000 datamodule, cada um dele só ocupará memória quando ele for instanciado, e ao ser
destruído será liberado a memória usada por ele, algo que não acontece nos cenários 1 e 2, tendo que deixa-lo por mais tempo ocupando memória para todos os forms do módulo use. 

b) Manutenção o código limpo, só com o necessário para aquele form, eventos dos componentes poucos e enxutos, seguindo padrão de projeto ou seja "dê a Cesar o que é de Cesar" 

Vamos a uma avaliação. 
Um datamodule nada mais é que um contêiner, você sabe de quem um datamodule é herdado? Se não sabe, um datamodule é herdado de um TComponent, ué TComponent? isso mesmo, o pai do datamodule é o mesmo pai de todos os componentes que você usa no seu sistema, mas por ele ter sua característica de um form, muitos restringe seu uso, datamodule não tem nada a vê com form, sua hierarquia é muito distante, veja a raiz até chegar em um Form.
TComponent
  |_TControl
    |_TWinControl
      |_TScrollingWinControl
        |_TCustomForm
          |_TForm
Um form precisa além dos componentes de acesso a dados e entre outros que necessários, do código de seus eventos e suas regras de negócio (regras de negócio jamais no datamodule), então se temos um datamodule para cada form o form terá só esse component a mais na memória além do que já irá precisar tendo o datamodule ou não, o que acontece no cenário 1 e 2. 

Bem, disse acima, regras de negócio jamais no datamodule, então como proceder? Simples usando padrões de projeto e criando classe com as regras negócio para cada necessidade e linkando os eventos dos componentes que estão no datamadule aos métodos criados na classe. 

Exemplo TClientDataSet para Cliente no TDatamodule, nele um evento ClienteBeforePost(Dataset: TDataSet)
type
  TClienteClassRegra = class
  public
    class procedure ClienteBeforePost(Dataset: TDataSet); 
  end; 
...

procedure TClienteClassRegra.ClienteBeforePost(Dataset: TDataSet)
begin
  // Regra de negócio aqui
end;
No TDatamudule só o código do evento, chamando o método da classe, deixando assim o datamodule limpo e a regra livre para serem usados em qualquer outro lugar quando preciso.
procedure TDataModule.ClienteBeforePost(Dataset: TDataSet)
begin
  TClienteClassRegra.ClienteBeforePost(Dataset);   
end;
E assim definindo métodos para cada evento usado, inclusive classe para eventos dos TFields como SetText, GetText, OnValidate etc..., tendo a classe, ela pode ser usada em vários datamodules, pois cada um só terá o ponteiro linkado, disparando a regra na classe.
Exemplo:
type
  TClienteFieldRegra = class
  public
    class procedure ClienteFieldNameGetText(Sender: TField; var Text: string;
      DisplayText: Boolean);
  end; 
...

procedure TDataModule.ClienteFieldNameGetText(Sender: TField; 
  var Text: string; DisplayText: Boolean);
begin
  TClienteClassRegra.ClienteFieldNameGetText(Sender, Text, DisplayText);
end;
Para melhorar ainda mais esse desacoplamento, indico o não uso de TField em Designer, crie-os em run-time, já faço isso a muitos anos, e tem algo que pode fazer isso para você de forma simples, conheça e usar o ORMBr.

6 comentários :

SAC Automação Delphi e Lazarus

SAC Automação Delphi e Lazarus
Assine nosso SAC Automação Delphi e Lazarus para ter suporte técnico especializado em desenvolvimento

Quem sou eu

Minha foto

Proprietário/Administrador de Empresa em TI (Tecsis Informática)
  • Autor dos projetos OpenSource ORMBr, e DBCBr
  • Autor dos componentes ACBrInstall, ACBrSped, ACBrPaf, ACBrInStore, ACBrDownload.

Total de visualizações

Postagem em destaque

ORMBr - Mapeamento objeto-relacional

Mapeamento objeto-relacional ( ou ORM, do inglês: Object-relational mapping ) é uma técnica de desenvolvimento utilizada para reduzir...

Todo os direitos reservados.. Tecnologia do Blogger.

Seguidores

Google+ Seguindores