Artigos Delphi FireDAC: utilização avançada

Por que eu devo ler este artigo:Neste artigo será visto a construção de uma aplicação de vendas que utiliza cadastros mestre-detalhe com a nova engine de acesso a dados do Delphi, o FireDAC.

Será visto como utilizar o aplicativo do FireDAC fora do IDE do Delphi para a criação de conexões. Veremos também como utilizar o Generator do Firebird para a geração de chaves para os identificadores de tabelas, recursos estes exclusivos do Firebird/Interbase.

Também serão vistos vários recursos avançados do FireDAC, como o tracing de conexões, mapeamentos de tipos de dados, tratamento de erros e recursos de Rowset Fetching para limitação de registros para tráfego de dados em redes lentas.

Ao desenvolvermos uma aplicação Client-Server com o Delphi, devemos tomar cuidado para não criarmos comandos SQL nos formulários. O Data Module foi criado justamente para concentrar os componentes de acesso a dados e todas as consultas necessárias.

O desenvolvedor pode achar mais fácil simplesmente ficar escrevendo instruções SQL nos formulários, porém, com o crescimento do sistema, sua manutenção no futuro será muito mais difícil, sendo que separando bem os formulários das queries tudo fica mais fácil.

Aplicativos que possuem estas regras de acesso a banco de dados em formulários, ferem o princípio de separação de interesses da orientação a objetos.

Respeitando este princípio, temos uma maior facilidade em realizar manutenção nestes sistemas, visto que uma alteração na interface não terá nenhum efeito no Data Module e vice-versa.

A separação de interesses está intimamente ligada ao padrão de projeto MVC (BOX 1), muito utilizado no desenvolvimento de aplicações web. Também diz muito a respeito dos conceitos de coesão e acoplamento de classes (BOX 2) da orientação a objetos. Este conceito nos indica que cada parte do aplicativo deve ter uma responsabilidade, e que esta não deve se misturar com outras, como acontece com os formulários e Data Modules.

Cada um tem uma responsabilidade e quando misturamos elas, estamos ferindo este importante princípio de desenvolvimento de software.

BOX 1. MVC

O padrão MVC ou Model-View-Controller, popularmente falando, pode ser considerado o ancestral de todos os demais padrões surgidos posteriormente (MVP e MVVM). Seu surgimento se deu ainda na década de 80, se tornando um padrão muito popular para a criação de aplicações Web.

No MVC o Controller é definido como o ponto de entrada para as requisições de usuário, decidindo inclusive como lidar com cada entrada deste. Este mesmo Controller acessa então a camada Model, que tem a incumbência de processar a requisição, cujo resultado final é exibido na camada View.

BOX 2. Coesão e Acoplamento

O grau de Coesão na Orientação a Objetos nos indica a forma como foi projetada uma classe no que tange ao seu foco. Isso quer dizer que quando mais focada for a classe em resolver um problema, maior será a sua coesão, o que é uma coisa boa. O principal benefício da alta coesão é que essas classes são mais fáceis de manter e são menos necessárias alterações frequentes nelas do que nas de baixa coesão. Outro grande benefício é que classes com alta coesão são mais fáceis de serem reutilizadas posteriormente.

Acoplamento é o grau de conhecimento que uma classe tem sobre outra. Se o único conhecimento que a classe X tem sobre a classe Y for o que a classe Y expos através de sua interface, então a classe X e a classe Y são fracamente acopladas, o que é muito bom. Porém, se a classe A se baseia em partes da classe B que não fazem parte de sua interface, então elas estão fortemente acopladas, o que não é uma boa prática em sistemas orientados a objetos.

Migrando de AnyDAC para FireDAC

Para os desenvolvedores que já utilizavam o AnyDAC, existem algumas poucas diferenças para o FireDAC para considerar na hora de fazer a migração.

A primeira alteração é na API, onde foram renomeadas todas as units e também os prefixos das classes. Com o FireDAC foi implementado o mecanismo de hierarquia de namespaces (BOX 3).

Antes tínhamos a seguinte estrutura no AnyDAC:

· uAD<camada><função>

Agora temos a seguinte estrutura de unit no FireDAC:

· FireDAC.<camada>.<função>.pas

Veja nos exemplos destas units:

· uADCompClient -> FireDAC.Comp.Client

· uADStanOption -> FireDAC.Stan.Option

· uADPhysIB -> FireDAC.Phys.IB

Já os nomes dos componentes foram prefixados com o FD ao invés do AD c ...

Fim do trecho gratuito • continue abaixo
CONTEÚDO EXCLUSIVO

Desbloqueie toda a DevMedia

  • +2000 artigos e vídeos
  • +40 trilhas sobre Front-end, Back-end, IA e muito mais
  • +5000 exercícios práticos
  • Mentorias ao vivo individuais
até 50% OFF
A partir de
R$ 79 /mês
Assinar agora