Blog – FAQ 1

Blog - FAQ 1Alô, pessoal, tudo certo? Vocês sabem o que é um FAQ? Trata-se de um acrônimo para Frequently Asked Questions, um documento que contém as perguntas e respostas mais frequentes sobre um determinado assunto. Desde que o blog foi publicado, tenho recebido várias questões por e-mail relacionadas ao desenvolvimento de software. Por este motivo, decidi criar um FAQ com as questões mais interessantes, com o objetivo de ajudar também outros profissionais com as mesmas dúvidas.

 

Como proceder no relacionamento entre a tabela “Nota Fiscal” e a tabela “Itens da Nota Fiscal”?
Um relacionamento Master/Detail ocorre quando há uma tabela pai (no seu caso, a Nota Fiscal) e uma tabela filha (Itens da Nota Fiscal), e é necessário interligá-las através de um campo, no qual chamamos de chave estrangeira
Pra ficar mais fácil, acompanhe a lógica: 
– Uma nota fiscal pode ter 1 ou N produtos 
– Um produto pode existir em 1 ou N notas fiscais

A letra “N” significa uma quantidade variável (1, 5, 10, 25…).
Quando nos deparamos com essa regra, dizemos que há uma relação de N para N, também denominada N:N ou muitos-para-muitos. Neste caso, é necessário criar uma tabela intermediária para acoplar dados das duas tabelas. Essa tabela irá receber a chave primária da tabela “Nota Fiscal” e também a chave primária da tabela “Produtos”, formando a tabela “Itens do da Nota Fiscal”.
Isso significa que, se uma nota fiscal for excluída, os itens do nota fiscal também deverão ser automaticamente excluídos. Em outras palavras, os itens da nota fiscal são órfãs da nota fiscal. Tecnicamente, dizemos que a “Nota Fiscal” é a tabela mestre e os “Itens do Nota Fiscal” é a tabela de detalhes. Portanto, temos um relacionamento Mestre/Detalhe:
– Mestre: Tabela “Nota Fiscal”
– Detalhe: Tabela “Itens da Nota Fiscal”

Este conceito, em UML, se chama Composição.
No Delphi, quando precisamos trabalhar com Composição, normalmente utilizamos tabelas temporárias. No blog há três artigos sobre como trabalhar com tabelas temporárias no Delphi. Espero que possam lhe ajudar!

 

A respeito do MVC, como você normalmente padroniza a localização das units de utilidades compartilhadas, ou seja, aquelas para trabalhar com arquivos INI, registro do Windows, informações do sistema, etc?
A localização dos arquivos de configuração/utilidade é particular de cada desenvolvedor.
Na verdade, o MVC apenas denota a prática de separar as classes de visão, modelagem e controle em diferentes camadas. Geralmente, eu crio 4 diretórios adicionais:

  • DAO: arquivos da camada de acesso a dados (mesmo que a princípio seja uma responsabilidade da Model, achei mais interessante separar as responsabilidades de modelagem das classes de persistência);
  • Dados: arquivo do banco de dados;
  • Util: classes de validações, backup, envio de e-mails e componentes em comum;
  • Arquivos: demais arquivos utilizados na aplicação (imagens, arquivos INI, XML, etc…).

Pode-se ainda criar uma pasta para o projeto, contendo o DPR e as DLLs necessárias (como o fbclient.dll para Firebird).
Mas volto a dizer: nada impede que você crie quantas pastas forem necessárias no diretório da sua aplicação. O importante é separar as unidades principais.

 

Em um projeto com arquitetura MVC, posso utilizar Interfaces?
Trabalhar com Interfaces é uma ótima opção para quem tem bastante conhecimento em Orientação a Objetos. De acordo com o contexto do seu projeto, você pode utilizar Interfaces na camada Controller para que todas as classes dessa camada sigam um contrato de métodos em comum, principalmente relacionado às validações. Outra opção é utilizá-las na camada DAO, já que a maioria das entidades terão métodos de inclusão, alteração, exclusão e consulta.
A arquitetura do software fica ainda mais rica se você conseguir complementar o MVC com alguns Design Patterns, como o Strategy, Builder, ObserverSingleton e Factory. Claro, vale ressaltar que não existe uma regra ou um padrão de utilização. Tanto o MVC quanto os Designs Patterns são modelos que você pode adaptar ao seu desenvolvimento, portanto, cada desenvolvedor (ou empresa de desenvolvimento) tem suas particularidades.

 

Sou iniciante em Delphi e gostaria de saber basicamente como utilizar a ferramenta de debug.
Segue abaixo uma explicação (bem básica) de como fazer uma depuração do código no Delphi.
No local do código-fonte que você deseja inspecionar (por exemplo, no clique de um botão), pare o cursor do mouse na primeira linha após o begin e pressione F5.
Repare que a linha fica em vermelho. Isso significa que definimos um breakpoint (ponto de parada) para inspecionarmos o código.
Agora, pressione F9 para rodar o aplicativo e execute o evento em que o erro ocorre.
Oberve que a tela do Delphi será exibida na linha de código que definimos o breakpoint.
A partir de agora, pressione F8 para acompanhar a execução de cada linha.
Continue pressionando F8 para avançá-las até o erro ocorrer. O Delphi irá “parar” na linha que gerou o erro. Sabendo qual é a linha, vai ser mais fácil você identificar a causa do erro.

 

Há alguma forma de ler um valor do arquivo INI em linhas? No meu caso, tenho várias linhas em um TMemo, e gostaria de desenvolver uma forma de gravar e ler essas linhas em um arquivo INI.
Os arquivos INI são gravados em uma estrutura onde cada chave pode ter somente um único valor. Portanto, não é possível colocar várias linhas em uma única chave.
Uma alternativa para este caso é armazenar o valor com algum tipo de delimitador, como a vírgula, o pipe ( | ) ou barras. Dessa forma, no Delphi, basta ler estes delimitadores e considerar cada palavra separada como uma linha. Por exemplo:

Chave=Valor1|Valor2|Valor3

Ao processar os delimitadores, a saída no TMemo seria:

Valor1
Valor2
Valor3

 

Gostaria de realizar backup do meu banco Firebird pelo Delphi. É possível?
Uma das alternativas para realizar backups é utilizar a ferramenta Gbak, disponível na pasta “bin” do Firebird.
Copie ele para dentro da pasta da sua aplicação (ele é bem pequeno), e utilize o comando abaixo para disparar a função de backup:

ShellExecute(0, nil,
  'C:\Aplicativo\gbak.exe',
  PWideChar(' -B -USER SYSDBA -PASSWORD masterkey '+
  'C:\Aplicativo\Banco.fdb ' +
  'C:\Aplicativo\Backup_Banco.fbk'), '', 0);

Substitua os parâmetros acima pelos caminhos do seu sistema, e lembre-se de adicionar a unit ShellAPI na uses do formulário. O GBak irá criar um backup do banco de dados com a extensão FBK, no qual poderá ser restaurado quando necessário.

 

Obrigado pela visita e até a próxima, pessoal!


Confira também os outros FAQs:

FAQ 01 | FAQ 02 | FAQ 03 | FAQ 04 | FAQ 05 | FAQ 06 | FAQ 07 | FAQ 08 | FAQ 09


 

Compartilhe!
Share on FacebookTweet about this on TwitterShare on LinkedInShare on Google+Pin on PinterestEmail this to someone

4 comentários

  1. mto bom msm, so acho q o backup do firebird de vez copiar o arquivo gbak, vc deveria conseguir localizar ele no diretorio padrao msm, ate pq acho q teria q terminar usando variaveis de ambiente o q tornaria a rotina bem legal
    outra coisa é q fiquei esperando a msm rotina so q pro mysql rsrsrs
    outra coisa é q talvez colocar a duvida com um conchete estilo active seria interessante [iniciante], [intermediario], [avancado], ja q tdas as duvidas ficaram misturadas, enfim, gostei mto, espero pelo FAQ2

    1. Valeu, Conde! Ainda não tive a oportunidade de desenvolver uma rotina de backup com o MySQL, mas postarei aqui no blog quando surgir, ok? Obrigado também pelas sugestões. Abraço!

  2. Obrigado por compartilhar seu tempo e seu conhecimento. Suas dicas são sempre práticas e muito úteis.

    Em POO, usar tabelas temporárias para resolver um problema mestre/detalhe quebra o paradigma MVC? Para manter o MVC, a composição deveria ser feita de outra forma? Se sim, você poderia dizer como?

    1. Obrigado mais uma vez pelo comentário, Roberto Carlos.
      Na abordagem do MVC, geralmente o registro mestre e os detalhes são tratados como objetos em um relacionamento master/detail. Por exemplo, você pode criar uma classe chamada “Venda” e, dentro dessa classe, criar uma lista de objetos da classe “ItensVenda”. Isso dá sentido à composição, ou seja, ao instanciar um objeto da classe “Venda”, você automaticamente cria uma lista de itens (details). Na prática, durante o cadastro de uma venda, basta preencher um objeto dessa classe (adicionando cada item na lista de objetos) e enviá-lo para a camada de persistência. Essa camada irá gravar o registro mestre e percorrer os detalhes (lista de objetos), gravando-os no banco de dados.
      Por outro lado, nada impede que você utilize tabelas temporárias. Ao invés de alimentar um objeto, você pode popular uma tabela temporária criada em tempo de execução. No método de gravação, percorra os registros da tabela temporária e, para cada registro, crie um objeto que será enviado para a camada de persistência.
      O conceito pode parecer um pouco complexo, mas é bastante funcional dentro do contexto da OO.

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

Preencha o campo abaixo * Time limit is exhausted. Please reload CAPTCHA.