Fala Radizeiro e Radizeira, tudo bem com vocês?
No post de hoje irei mostrar como podemos utilizar o Clean Code para banco de dados.
Sair um pouco do arrastar componentes para tela.
Vamos simular como seria uma estrutura normal, de como faríamos para se trabalhar com Delphi de forma rad.
E como poderíamos fazer de forma organizada, dentro do código, para que tenhamos tempo, e que nosso código fique mais desacoplado possível.
Lembrando que , sem ir muito afundo em conceitos de MVC e POO.
Isso é para que você possa aplicar no seu código ainda hoje.
O que iremos fazer primeiro aqui é criar um exemplo para que você possa compreender de como é feito.
Onde irei adicionar uma conexão com o banco de dados.
Se você observar no Data Explorer do Dephi, já possui uma conexão com um banco de dados SQLite, com suas respectivas tabelas.
E como nós trabalhamos normalmente com o Delphi para criarmos as telas?
Observe que adicionei um DBGrid, e linkamos esse nosso DBGrid a uma dessas tabelas.
Onde foi criado uma conexão e possuímos uma tabela, e para que essa tabela esteja linkada ao DBGrid, usamos um DataSource.
O Delphi nos dá essa praticidade de forma prática e rápida, não é?
E já podemos rodar o projeto e disponibilizar, simples assim não é pessoal?
Mas qual é o grande problema?
Isso é muito fácil para começarmos um projeto pequeno.
Mas quando o projeto vai crescendo, vai ganhando corpo, você começa a ter um grande problema de acoplamento.
E o que é o acoplamento?
Tenho um único formulário, uma camada de visão, onde ele está intimamente arraigado com regras de negócios e coisas que não são de sua responsabilidade.
Como por exemplo um FDConnection, um FDQuery, que são propriedades de conexão que não deveriam estar na camada de visão, e sim dentro do model.
E o que isso acarreta, afinal de contas?
Você pode estar pensando, que não está vendo nenhum problema.
Mas o problema é que muitas pessoas hoje têm seus códigos, relativamente legados porque, lá atrás, começaram a trabalhar com Delphi desta forma.
E ainda utilizaram o antigo BDE, e depois o Delphi lançou o DBExpress, e muita gente ainda está agarrada no BDE, por não conseguiram atualizar essas conexões.
Isso tudo acontece por estarem totalmente acoplados.
Porque em cada tela do seu sistema, estão com os componentes na tela, com vários códigos, com várias regras de negócios na tela, amarrados aos componentes.
Então na hora de você fazer uma alteração, isso é muito custoso.
Se torna muito difícil essas atualizações.
Imagina um projeto com 500, 1000 telas…
Como você troca o Firedac por um outro componente de acesso a dados?
Muito difícil, não é verdade?
Seu código é fácil para começar a fazer, mas depois para dar uma manutenção neste código é muito mais difícil, é muito mais complexo.
Espero que você possa compreender o que estou querendo lhe mostrar, para que você realmente visualize a melhor dos seus códigos.
O ideal é que sua tela esteja independente dos componentes de conexão.
Que ela possa funcionar independentemente de quem esteja realizando o processo de acesso a dados.
E caso você tem interesse de conhecer mais sobre Boas Práticas para conexão de dados acesse o nosso portal do CLUBE DE PROGRAMADORES EM DELPHI.
Você não terá só conteúdos relacionados ao Boas Práticas para conexão de dados, mas uma quantidade enorme de conteúdos que poderá lhe ajudar muito no seu dia a dia, é uma verdadeira NETFLIX para os programadores Delphi.
CLIQUE AQUI E SAIBA MAIS SOBRE O CLUBE DOS PROGRAMADORES DELPHI
