Blog – FAQ 6

Blog - FAQ 6Olá, pessoal!
O artigo de hoje é mais uma compilação de perguntas e repostas dos leitores! A intenção é alimentar cada vez mais a base de conhecimento do blog e ajudar novos visitantes. Antes que eu me esqueça, gostaria novamente de agradecer a todos pelas visitas, comentários, elogios e sugestões! Get ready!

 

Stored Procedures deixam a aplicação mais rápida?
Se o desenvolvedor colocar uma regra de negócio em uma Stored Procedure, significa que ele não terá que implementá-la na aplicação, uma vez que ela será executada no banco de dados. Sendo assim, haverá uma redução nas linhas de código, resultando em uma aplicação menor, mais rápida e descentralizada.
Por outro lado, há também os casos de aplicações cliente/servidor. Como são vários usuários conectados no mesmo banco de dados ao mesmo tempo, talvez Stored Procedures possam impactar no desempenho. Em outras palavras, ao serem executadas por vários usuários enquanto ainda trata de outras transações, o motor do banco de dados pode ficar “sobrecarregado”, ou seja, além de gerenciar consultas, inserções e atualizações, o banco de dados também ficará responsável por algumas regras de negócio.
Enfim, é algo relativo. Alguns profissionais recomendam a distribuição das regras de negócio entre a aplicação e o banco de dados de acordo com a camada de requisitos que elas representam.

 

É possível disparar Stored Procedures pelo Delphi?
Sim! Já existe alguns componentes no Delphi que permitem a execução de Stored Procedures, como seguem:

  • Se você estiver utilizando o conjunto ADO, o nome do componente é TADOStoredProc;
  • Se estiver utilizando DBX (dbExpress), o componente é o TSQLStoredProc;
  • Caso esteja utilizando IBX (Interbase), utilize o TIBStoredProc.

Para configurá-lo, basta setar a propriedade de conexão e o nome da Stored Procedure que está no banco. Por fim, para dispará-la, chame o método ExecProc:

Componente.ExecProc;

 

(colaboração do leitor Ricardo Silva no artigo “[Delphi] Envio de e-mail com componentes Indy“)
Consegui enviar e-mails pelo Delphi utilizando os servidores do Terra. Aqui vai a dica:

// Configuração do SMTP
IdSMTP.AuthenticationType := atLogin;
IdSMTP.Port := 587;
IdSMTP.Host := 'smtp.sao.terra.com.br';
IdSMTP.Username := 'email@terra.com.br';
IdSMTP.Password := 'senha';

 

(dúvida referente ao artigo “[Delphi] Envio de e-mail com componentes Indy“)
No meu caso, preciso enviar o mesmo e-mail para mais de um destinatário, é possível?
Ótima pergunta. Para enviar o e-mail para mais de um destinatário, basta substituir a linha:

IdMessage.Recipients.EMailAddresses := 'destinatario@email.com';

por:

IdMessage.Recipients.Add.Text := 'destinatario1@email.com';
IdMessage.Recipients.Add.Text := 'destinatario2@email.com';

 

(dúvida referente ao artigo “Quais Design Patterns devo usar no meu projeto?“)
O DER também pode ser utilizado para definir os Design Patterns?
Sim, o DER também pode ser empregado para este propósito, porém, eu recomendaria o Diagrama de Classes, principalmente por apresentar características pertinentes a Orientação a Objetos, como os atributos, métodos, heranças e definições de visibilidade. Além disso, algumas propriedades do Diagrama de Classes são úteis para a elaboração de outros diagramas da UML, o que também pode amparar os desenvolvedores nessa questão.

 

“Interface” é o visual de uma aplicação, certo?
O termo “Interface” no cenário de TI é bem ambíguo. Você está certo, Interface pode ser o visual da aplicação que é apresentado ao usuário, porém, no contexto da Orientação a Objetos, Interface é o nome que se dá a um recurso para trabalhar com abstrações. O objetivo das Intefaces é prover flexibilidade na estrutura de software de modo que resulte em um baixo acoplamento (dependência) entre classes. Ao invés de trabalhar com implementações concretas, as Interfaces podem ser utilizadas para representar as abstrações no projeto de software em nível de modelagem.
A parte 9 do artigo sobre dicas de desenvolvimento mostra um exemplo teórico de utilização de Interfaces.

 

Tenho um sistema que emite NF-e, mas ele está todo procedural, nada de Orientação a Objetos. Na sua opinião, o que seria mais ideal: migrar o sistema usando conceitos de RTTI e Orientação a Objetos ou refazer o sistema do zero?
No meu ponto de vista, optar por migrar ou refazer o software depende do nível de complexidade, tanto na arquitetura quanto na regra de negócio. Quanto maior a quantidade de unidades de código-fonte, mais demorada será a fase de migração. Além disso, convenhamos que, o mesmo tempo que você irá gastar para transformar o código procedural em Orientado a Objetos será basicamente o mesmo tempo que você levará para modelar o projeto do zero, portanto, eu optaria por refazer o software.
Na verdade, já passei por uma situação parecida e optei pela remodelagem do software. O interessante é que enquanto eu criava novamente as telas e as classes, descobri novas formas de tratar as regras de negócio e apliquei uma série de refatorações. No final das contas, reduzi 40% do código e melhorei a expressividade utilizando Clean Code.
Porém, lembre-se também de levar o prazo em consideração, bem como as ferramentas e tecnologias que irá utilizar. Talvez apenas migrar o sistema aos poucos (de forma incremental) pode ser a opção mais viável.

 

(dúvida referente ao artigo “Programador Júnior, Pleno ou Sênior – Quem eu sou?“)
Gostaria de saber em qual categoria os desenvolvedores autônomos se encaixam. Geramente eles criam, constróem e testam a aplicação utilizando diferentes técnicas que podem ser particulares de cada desenvolvedor.
Já tive a mesma dúvida e cheguei à conclusão de que o nível do programador autônomo está intimamente ligado aos anos de experiência e principalmente aos projetos que ele já participou. Claro, e não devemos esquecer também do domínio na regra de negócio. Por exemplo, caso o desenvolvedor tenha trabalhado com programação na área de automação comercial, é bem provável que ele se torne um programador pleno ou sênior ao ser contratado por uma empresa que desenvolve softwares para esse segmento, já que ele terá um conhecimento considerável.
Sendo um pouco mais específico, acredito que não exista uma maneira exata de encaixar um desenvolvedor autônomo em um dos níveis, ao menos que ele tenha alguma certificação que comprove a sua excelência. Mesmo assim, há algumas formas de “medir” o próprio nível de conhecimento, como participar de fóruns sobre programação, discutir com outros profissionais, praticar katas e criar um portifólio do seu trabalho.

 

Na prática, qual o benefício do MVC na estrutura do projeto?
O MVC é um padrão de arquitetura que tem como objetivo principal a separação de responsabilidades das classes do projeto. Dessa forma, uma das vantagens é a versatilidade dos componentes.
Imagine, por exemplo, um determinado componente da aplicação que foi construído em MVC. Em certo momento, identificou-se que este componente terá de ser utilizado em outra parte da aplicação, mas com um visual diferente. Neste caso, basta substituir somente a View e reutilizar o Model e o Controller. Em outras palavras, pode-se dizer que “removemos” a View do componente e “encaixamos” outra conforme a nossa necessidade. As regras de negócio (Model) e os controladores (Controller) serão os mesmos.
Se o seu projeto contemplar esse tipo de cenário, utilizar o MVC será um grande benefício. Além dessa vantagem, ainda podemos citar a facilidade de manutenção, baixo acoplamento e, claro, redução e organização do código-fonte.

 

Como os padrões de projeto se relacionam com MVC?
Design Patterns são extremamente úteis ao utilizar MVC. Não é uma regra, mas como são grandes aliados da Orientação a Objetos, podem complementar ou enriquecer a arquitetura do projeto.
Por exemplo, na empresa em que trabalho, utilizamos o Singleton para acessar classes compartilhadas, Builder para construir componentes em tempo de execução, Factory Method para criar Datasets, Observer para notificar componentes ao disparar eventos e Strategy para tratar algumas regras de negócio. Já que a maioria dos padrões de projeto fazem uso de Interfaces, fica relativamente fácil acoplá-los ao MVC.
Vale ressaltar que padrões de projeto podem ser utilizados em qualquer ocasião. Sempre que o desenvolvedor se deparar com uma situação na qual um padrão de projeto possa apresentar uma solução, é altamente recomendável implementá-lo, mesmo se não estiver utilizando um padrão de arquitetura.

 

A camada DAO deve ser sempre criada em um projeto com MVC?
A camada DAO é uma “extensão” da camada Model. Muitos programadores decidem criá-la para separar as regras de negócio da persistência no banco de dados.
Assim como a camada Model, outras camadas podem ser estendidas. Certa vez, encontrei um projeto no qual os desenvolvedores estenderam a camada View para implementar um WebService. Neste caso, uma camada View ficou responsável pela aplicação desktop e outra pela aplicação Web. Bem interessante!
Observe que elas não são novas camadas, são apenas extensões das camadas já existentes. Ainda mais que, se criássemos novas camadas, fugiria da diretriz do MVC.

 

(dúvida referente ao artigo “[Delphi] Tabela temporária com ClientDataSet – Final“)
Após criar a tabela temporária, posso adicionar novos campos?
Infelizmente não é possível adicionar novos campos, já que essa operação alteraria a estrutura interna do DataSet. Sendo assim, é necessário remover todos os campos existentes e adicioná-los novamente:

ClientDataSet1.Close;
ClientDataSet1.FieldDefs.Clear;
// adicione todos os campos anteriores e os novos campos
ClientDataSet1.CreateDataSet;

 

Abraço!


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

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.