Guia Delphi

FireMonkey e FireDAC: Construindo uma aplicação completa – Parte 1

Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Para efetuar o download você precisa estar logado. Clique aqui para efetuar o login
Confirmar voto
0
 (1)  (0)

Neste artigo veremos como desenvolver uma aplicação completa de Ordens de Serviço utilizando o FireMonkey para construir as interfaces gráficas, e o FireDAC para o acesso a dados.

Fique por dentro
Atualmente o Delphi dispõe de dois frameworks para o desenvolvimento visual de aplicações: o VCL (Visual Component Library) e o FireMonkey. O primeiro é muito conhecido pelos desenvolvedores desktop, pois acompanha o Delphi desde as primeiras versões, e é caracterizado por funcionar somente no Windows. Por outro lado, o FireMonkey é um framework mais recente, e sua característica principal é gerar aplicações nativas tanto para Windows quanto para OS X, Android e iOS. Dessa forma, é importante o conhecimento sobre como utilizar os componentes desse framework para construir aplicações também com características desktop, porém que possam ser executadas em um número maior de dispositivos.

O Delphi sempre foi considerado uma das melhores IDEs para o desenvolvimento de aplicações desktop, possuindo uma gama de recursos que agilizam muito o trabalho dos programadores e contribuem para o rápido desenvolvimento de softwares comerciais. Nesse contexto, o VCL é o conjunto de componentes mais utilizado para a programação de softwares nesse estilo, sendo compatível somente com o Windows. Porém, como a utilização de diferentes sistemas operacionais (como OS X, Android e iOS) cresceu muito nos últimos anos, o Delphi passou por uma evolução natural, e foi criado o framework FireMonkey, que é compatível com todos esses sistemas operacionais, inclusive com o Windows.

Portanto, uma vantagem do FireMonkey sobre o VCL é que ele permite que um software seja compilado com código nativo para múltiplos dispositivos sem a necessidade de alterações no código fonte, desde que esse seja criado com componentes compatíveis. Dessa forma, esse framework oferece muitas vantagens para os desenvolvedores, porém existem algumas diferenças com relação a alguns componentes, como a ausência do DBGrid, que é um dos componentes mais utilizados para a listagem de registros. Esse fato acaba gerando um problema no processo de adaptação que os desenvolvedores precisam passar para começarem a utilizar o FireMonkey ao invés do VCL (quando aplicações multidispositivos são necessárias).

Tendo essa necessidade como base, o objetivo deste artigo é apresentar uma visão prática de como construir uma aplicação completa passo a passo utilizando o framework FireMonkey, o Delphi 10.1 Berlin e a engine FireDAC de acesso a dados. Nesta primeira parte serão mostrados os processos para a criação da base de dados de um cenário de ordens de serviços de um auto center, a definição do menu principal com acesso às janelas do sistema e, por fim, o desenvolvimento de uma tela padrão de pesquisa, que será utilizada como janela base para as outras telas (utilizando herança). As próximas seções mostram o desenvolvimento completo do software.

Entendendo a base de dados

A Figura 1 apresenta o modelo entidade relacionamento da base de dados, a qual é composta por seis tabelas. Na parte central do diagrama, encontra-se a tabela m_ordem_servico, a qual armazenará as principais informações sobre o cenário proposto. Para isso, ela se liga por meio de chaves estrangeiras às tabelas de clientes, formas de pagamento e veículos, ou seja, quando uma ordem de serviço for preenchida pelo usuário o mesmo terá que informar esses campos.

Considerando o cenário de auto center, quando um veículo é enviado para manutenção vários serviços podem ser realizados, como geometria, balanceamento, rodízio de pneus, lavação, entre vários outros. Dessa forma, uma ordem de serviço pode possuir vários serviços, enquanto que um mesmo tipo de serviço pode ser executado em várias ordens de serviço. Esse raciocínio nos leva a conclusão que esse relacionamento é do tipo muitos para muitos (N-N), o que requer que seja criada uma nova tabela, comumente chamada de entidade associativa, a qual fará a ligação entre as tabelas m_ordem_servico e c_servico. Esse relacionamento é demonstrado pela tabela m_ordem_servico_servico, que possui duas chaves estrangeiras: uma relacionando com a tabela m_ordem_servico e outra com a tabela c_servico. Em outras palavras, esse vínculo entre as tabelas caracteriza o recurso de mestre-detalhe, que é muito comum e de extrema importância para qualquer sistema comercial.

É importante enfatizar que a tabela c_servico armazenará o cadastro de todos os serviços ofertados pela loja, enquanto que a entidade associativa tem a função de registrar somente os serviços relacionados a uma ordem de serviço.

Modelo entidade
relacionamento da base de dados

Figura 1. Modelo entidade relacionamento da base de dados.

Criando a base de dados

Após o entendimento da estrutura da base de dados, o próximo passo é efetivamente criá-la no MySQL por meio da linguagem SQL. A Listagem 1 apresenta os scripts para a definição das tabelas de cadastro, as quais possuem o prefixo “c” no início do nome. Na linha 01 a base de dados é criada, com o nome ordem_servico, enquanto que o restante do código apresenta a definição das tabelas de formas de pagamento (linhas 03 até 08), serviços (linhas 09 até 14), veículos (linhas 15 até 21) e clientes (linhas 22 até 30).

É possível observar que todas as tabelas possuem uma chave primária do tipo autoincremento, ou seja, os identificadores serão gerados automaticamente pelo MySQL. A engine de acesso a dados que usaremos será o FireDAC, o qual já possui recursos nativos para identificar campos do tipo autoincremento automaticamente independente do sistema gerenciador de banco de dados (consulte a seção Links para mais detalhes).

Listagem 1. Criação das tabelas de cadastro.

  01 create database ordem_servico;
  02 use ordem_servico;
  03 create table c_forma_pagamento (
  04   idforma_pagamento int not null auto_increment,
  05   nome varchar(20) not null,
  06   observacao text, 
  07   constraint pk_fp_idforma_pagamento primary key (idforma_pagamento)
  08 );
  09 create table c_servico (
  10   idservico int not null auto_increment,
  11   nome varchar(30) not null,
  12   observacao text, 
  13   constraint pk_sv_idservico primary key (idservico)
  14 );
  15 create table c_veiculo "
[...]

A exibição deste artigo foi interrompida :(
Este post está disponível para assinantes MVP

 
Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Ficou com alguma dúvida?