Post: [Boas práticas para conexão de dados] Consumindo os Dados na View

Alessandro Medeiros

Fala Radizeiro e Radizeira, tudo bem com vocês?

Em toda a nossa série trabalhamos no intuito de reduzir o acoplamento das aplicações desenvolvidas com o Delphi.

E para que isso venha ser feito você precisa primeiro sair do que hoje têm desenvolvido, que é a forma procedural.

Sei que para você hoje isso pode parecer simples e de fácil entrega para seus clientes.

Mas pare para pensar em quantas vezes, e quanto tempo você já levou para solucionar um problema.

E ainda mais em questões de atualizações de bibliotecas, ou até mesmo migração para novas versões do Delphi.

E claro, tentar seguir padrões que o governo aplica em documentos fiscais, e dentre outras normas.

Trabalhar dessa forma gera uma demanda muito grande.

Ao resolver um problema, pode acarretar outro, tudo devido ao acoplamento.

Então se hoje você quer melhorar sua aplicação para ser menos acoplada, e menos dependente de componentes de terceiros, é importante começar pela camada mais baixa.

Cada essa que estou relatando é a conexão, depois que conseguir desacoplar sua conexão e ter a possibilidade de utilizar qualquer outra sem que tenha que alterar nada nas outras camadas, você já terá um trabalho muito menor e a oportunidade de desacoplar o restante do seu software.

E agora vamos de fato para a tela, depois de desacoplar toda a nossa conexão e acesso a dados, agora vamos para a camada visual do nosso exemplo.

E iremos ver como colocar para funcionar.

Agora temos um código totalmente desacoplado.

E para isso na nossa camada view devemos remover tudo que é uses que não estamos utilizando, que está relacionado ao Firedac.

Como nossa view não tem mais nada de componente de conexão, vamos começar o trabalho de saneamento básico.

E agora, já que nossa camada de visão irá trabalhar com a entidade de usuário, basta que venhamos dar visibilidade a interface de entidade.

TForm1 = class
...
private
FUsuario : iEntidade;
...

Observe que nosso objeto é do tipo da interface, nada de programar orientado a classe.

Com esse nosso objeto, vamos para o create dessa nossa view, para que possamos instanciar esse usuário.

procedure TForm1.FormCreate(Sender: TObject);
begin
FUsuario := TModelEntidadeUsuario.New;
end;

Observe que agora todas as vezes que o formulário for criado irei ter um objeto usuário para que possa ser usado.

Quando este objeto estiver instanciado, ele já instância a classe de conexão, a query, ele já sabe tudo que tem que fazer.

Então simplesmente eu irei para o evento onClick do botão e listar os dados, passando as informações para o DataSource, ou seja, alimentando ele com os dados vindos do banco.

procedure TForm1.Button1Click(Sender: TObject);
begin
FUsuario.Listar(DataSource1);
end;

Agora basta eu compilar o projeto e clicar no botão para que os dados venham ser preenchidos na tela.

Observe que é listado todos os nossos usuários com um código totalmente desacoplado.

Vamos vincular também nosso DBNavigator ao Datasource, para que possa ser trabalhada nossa aplicação tranquilamente.

Um exemplo bem simples de como você já pode aplicar nos seu dia a dia, seguindo cada post dessa nossa série tenho certeza que você irá poder evoluir e muito sua aplicação.

Essa é uma estrutura, mais ou menos, de um projeto utilizando MVC, se você ainda optar por trabalhar de forma RAD.

Utilizando diretamente os componentes.

Observe que não estou utilizando ORM nenhum, nenhum mapeamento de dados do banco.

Tudo que quero fazer com o usuário, eu faço dentro da entidade do mesmo.

Dentro da query, se eu desejar filtrar, criar um outro tipo de lista passando os campos que eu quero que retorne.

Vamos simular essa questão de listar os campos que desejamos?

Na nossa interface de Entidade irei adicionar um método chamado ListarCampos.

E esse método recebe como parâmetro um DataSource, e os Fields.

iEntidade = interface
function Listar(Value : TDataSource) : iEntidade;
function ListarCampos(Fields : String; DataSource : TDataSource) : iEntidade;
end;

Desta forma estou dizendo para ele o que eu quero que retorne.

Agora toda minha entidade irá precisar desse método listar.

Esse nosso lista terá a implementação igual ao anterior, porém dentro do * do SQL, irá receber o Fields.

function TModelEntidadeUsuario.ListarCampos(Fields: String;DataSource: TDataSource): iEntidade;
begin
Result := Self;
FQuery.SQL('select '+Fields+' from users');
DataSource.DataSet := FQuery.DataSet;
end;

Agora já temos um novo método para trabalhar dentro do nosso projeto.

Precisei mexer na minha tela?

Precisei mexer no componente de conexão?

Ai mais, precisei mexer no componente query?

Não precisei fazer nada com relação a eles.

Simplesmente precisei mexer somente na entidade específica de usuários, e sua interface.

Muito tranquilo não é pessoa?

Olha como um código desacoplado facilita a manutenção dos nossos projetos.

Agora simplesmente posso ir na camada de visão e colocar por exemplo um edit para filtrar os campos que eu quero, não é uma busca por enquanto, mas você pode fazer isso dentro do where do SQL.

Mas por enquanto quero que somente liste os campos que eu desejar.

Dentro desse botão que adicionamos, iremos chamar o método para listar os campos que desejamos.

procedure TForm1.Button2Click(Sender: TObject);
begin
FUsuario.ListarCampos(Edit1.Text,DataSource1);
end;

Observe como nosso código fica limpo e de fácil aplicabilidade.

Esses são os benefícios de trabalhar com o desacoplamento.

O legal é que não temos nada nessa nossa tela, nenhum componente.

Somente um DataSource, é o componente mais básico que toda versão do Delphi tem.

Agora, simplesmente com o nosso projeto rodando, posso adicionar os campos que quero que sejam visualizados pronto.

Observe que agora eu tenho somente os campos que eu defini no meu edit, muito legal não é?

Nesse edit poderia ser um where, onde você coloca os campos que você quer filtrar, dentre outras possibilidades.

O que eu fiz aqui nesta nossa série de post, de uma forma simples e prática, mostrar para vocês como é possível você fazer um código limpo, e de forma bem rápida.

Desta forma conseguimos fazer com que o nosso projeto tenho um vida útil muito mais longa, e conseguiremos economizar, pelo menos 50% do nosso tempo no dia a dia.

Vale a pena estudar as boas práticas, estudar Clean Code.

Isso que fizemos na nossa série, lógico, tem muita coisa de MVC, de Design Pattern, e muito mais.

Mas se esses conceitos entrarem em sua cabeça, o clean code, o princípio da responsabilidade única.

Onde você desenvolve de uma forma que cada classe faz um coisa.

Se entrar esses princípios do SOLID entrar na sua mente, e você entender a importância disso, você irá poder ter um código bonito, e bem escrito como esse.

Onde cada botão com apenas uma linha de código, e sem a necessidade de fazer coisas que deixamos acoplados e com um monte de componentes na tela.

Executando um monte de coisa sem necessidade em nosso projeto.

Espero que essa nossa série tenha lhe ajudado.

E para que você possa se aprofundar ainda mais, e não esteja no Clube dos Programadores Delphi, convido você a participar.

Faça sua busca

CATEGORIAS

POSTS RECENTES

E caso você tem interesse de conhecer mais sobre [Boas práticas para conexão de dados] Consumindo os Dados na View, 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] Consumindo os Dados na View, mas uma quantidade enorme de conteúdos que poderá lhe ajudar muito no seu dia a dia, é uma verdadeira NETFLIX para os programadores Delphi.
Gostou?
Compartilhe:

Embarque no foguete com milhares de devs para aprender desenvolvimento, evoluir de forma contínua e se manter relevante no mercado.

Dúvidas
Cadastre-se em nossa lista

Para ter acesso em primeira mão, a tudo que acontece na Academia do Código, basta se cadastrar em nossa lista

Grupo Thulio Bittencourt | Academia do Código

#FaçaPartedaHistória

Copyright © 2024 – Todos os direitos reservados