FireDAC: utilização avançada

Aprenda neste artigo como utilizar o FireDAC para realização de cadastros mestre-detalhes e como resolver de forma eficiente situações como geração de chaves primárias e tratamento de erros.

Fique por dentro
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 como existia anteriormente.

Para quem está em versões anteriores do Delphi com AnyDAC e deseja migrar para uma versão mais recente com FireDAC, existe um aplicativo que facilita esta migração chamado reFind.exe que se encontra na pasta Bin do diretório de instalação do Delphi.

Os pacotes em tempo de execução (Runtime packages), também foram renomeados. Ex: FireDACCommon190, FireDACCommonDriver190.

Os arquivos de inicialização também foram renomeados de ADxxx para FDxxx e tiveram uma mudança no local, agora presentes em C:\Users\Public\Documents\Embarcadero\Studio\FireDAC.

BOX 3. Namespaces no Delphi

O mecanismo de namespaces no Delphi foi introduzido desde a versão XE2 do IDE, principalmente devido a introdução do FireMonkey. Desta forma, podemos ter duas units com o mesmo nome final igual e namespaces diferentes, como existe na VCL e Firemonkey. Ex: Vcl.Forms, FMX.Forms. FMX.StdCtrls, Vcl.StdCtrls.

FireDAC Explorer"

 [...] continue lendo...

Artigos relacionados