Um conhecimento só é válido quando compartilhado.

segunda-feira, 15 de maio de 2017

SAC Fiscal & Automação



Seja bem-vindo ao primeiro SAC Fiscal e Automação Comercial para software houses, aqui você vai ter o apoio necessário tanto para entender a legislação quanto para desenvolver o necessário para atender as mudanças de legislação.
Atendimento sobre dúvidas e procedimentos fiscais para Software Houses e seus sistemas.

SAC Fiscal

  • Dúvidas sobre notas técnicas, NF-e, NFC-e, S@T, NFS-e e CT-e
  • Cálculos de tributação, ICMS, ICMS-ST, PIS e COFINS
  • Auxilio na modelagem de seu banco de dados para Tributação e emissão de documentos fiscais
  • Notificação sobre liberação de notas técnicas

SAC Automação

Atendimento sobre dúvidas e codificação em Delphi para seus sistemas, auxiliando no desenvolvimento para os seguintes seguimentos.
  • Suporte ao desenvolvimento de NF-e, NFC-e, S@T, MDF-e, Paf-ECF, GNR-e e outros a nível de codificação
  • Auxílio e dicas em boas práticas e técnicas em automação comercial
  • Técnicos com experiência ao seu lado sanando dúvidas e orientando nas melhores soluções de seus problemas e necessidades relativas ao desenvolvimento de rotinas fiscais
  • Atendimento em até 72 horas

sexta-feira, 5 de maio de 2017

DBCBr - Database Compare Brasil

O DBCBr, é um framework que tem como finalidade comparar e atualizar estrutura de banco de dados, como ele é um framework e ainda não uma ferramenta, seu código pode fazer parte da sua app.
DBCBr nasceu juntamente com o ORMBr, pois o mesmo o usa para fazer as atualizações do banco com base nos modelos, e como o ORMBr é uma tecnica ainda não tão bem difundica e usada, achei por bem, criar um novo projeto com esse recurso, o qual a pesar de muitos já fazerem pelo seus sistemas atualização de banco de dados, também muitos ainda não tem, e se tem pensam em melhora-lo.
O DBCBr, ainda não está maduro em recursos, mas está em estrutura, ou seja sua estrutura interna está pronto para atender qualquer necessidade, para comparar, identificar e gerar o script de atualização de qualquer banco de dados relacional.
Nós sabemos que atualizar banco de dados não é tão simples como parece, pois regras de integridade, as quais usamos e devemos usa-las, atrapalha no momento de executar o script de atualização, tendo que nos preocurar com vários detalhes e ordens, seja ele para criar algo novo, mudar algo que já exista ou até mesmo dropar algo existente, por essas razões o crescimento do DBCBr depende de testes e a ajuda de vocês, no que diz repeito a melhor forma de executarmos cada scripts de atualizações gerados.
O crescimento do DBCBr irá gerar o crescimento também do ORMBr, que o usa como complemento de recurso, agora quer uma ferramenta de Database Compare boa e de graça, estude o código do DBCBr, vamos discutir juntos, vamos unir conhecimentos e assim teremos o que precisamos, e com isso todos ganham, EU, Você e o ORMBr.
Estou a disposição para qualquer discussão sobre o assunto, novidades, dúvidas, discussões podem ser feito através do mesmo canal/grupo do ORMBr 

Canal: https://t.me/canalormbr
Grupo: https://t.me/ormbr

domingo, 23 de abril de 2017

Mitos Sobre os TDataModules

Seja bem vindo, e ótima leitura.
Teve uma discussão sadia sobre o uso de datamodule no face postado por Savério Vertoni Jr. em cima da seguinte imagem: 
Sou do signo de gêmios, dizem que quem é de gêmios quer convencer as pessoas da sua verdade ou do que acham que é verdade, eu particularmente gosto de usar fundamentos para mostrar o que acredito ser a minha verdade, claro temos livre arbítrio para escolhermos o que achamos que é melhor para nós, isso nós chamamos de liberdade de expressão. 
Agora podemos sim expor o que achamos certo e se quisermos que alguém acredite façamos da forma concreta, mostrando o porque da opinião, e talvez ai, alguém irá vê que sua opinião tem base para ser verdade ou não. 
Nesse poste podemos ver alguns cenários para exemplificar o uso de datamodules é sobre o que visualizei que vou comentar. 
Os comentários do post foi com base em uma pratica totalmente inviável como visto na imagem acima, vou explicar porque, também teve comentários que disseram que devemos criar um datamodule por módulo de sistema, também inviável, vou explicar porque, e comentário sobre o que disse o Vertoni em cria datamodule por form, "haja memória", isso é mito, pois uso de datamodulo por form não estoura memoria, na minha opinião á a melhor maneira de se usar datamodule, vou explicar porque.

Cenário 1 - Uma datamodule único com tudo nele, como mostrado no na imagem do post é inviável porque?
 
a) Teremos que instância-lo no inicio da aplicação, isso irá sobrecarregar a abertura da app pela quantidade demaciada de componentes
b) Terá que ficar disponível enquanto a aplicação estiver aberta, pois todo mundo dependerá de usa-lo. 
c) Manutenção no fonte desse datamodule, tente visualizar o fonte com os vários eventos de cada um componente ativo, impraticável implementar, corrigir, achar algo de forma escalável, pois terá rotina que atenderá a todo mundo.

Cenário 2 - Datamodule por módulo de sistema é inviável porque? 

a)
Independente de como se organiza quais componentes colocar no datamodule de cada módulo, sempre terá nesse datamodule informações que não será usado por alguma situação, e nesse momento tenho informações na memória desnecessárias. 

b) Terá que ficar disponível sempre, pois a qualquer momento, algum form que faz parte do módulo precise acessa-lo. Agora se criar um para cada form  que precise dele, pior ainda, ai inchar a memória mesmo, cada um com um montão de coisa desnecessária. 
c) Manutenção no fonte desse datamodule, tente visualizar o fonte com os vários eventos de cada um componente ativo, impraticável implementar, corrigir, achar algo de forma escalável, pois terá rotina que atenderá a todo módulo. 

Cenário 3 - Datamodule por Form, haja memória, mito, para mim é a melhor forma a ser usada.

a)
"Haja memória" porque? Se o datamodule só deve ser criado no Create form e liberado do Destroy? Se no EXE tem 1000 datamodule, cada um dele só ocupará memória quando ele for instanciado, e ao ser
destruído será liberado a memória usada por ele, algo que não acontece nos cenários 1 e 2, tendo que deixa-lo por mais tempo ocupando memória para todos os forms do módulo use. 

b) Manutenção o código limpo, só com o necessário para aquele form, eventos dos componentes poucos e enxutos, seguindo padrão de projeto ou seja "dê a Cesar o que é de Cesar" 

Vamos a uma avaliação. 
Um datamodule nada mais é que um contêiner, você sabe de quem um datamodule é herdado? Se não sabe, um datamodule é herdado de um TComponent, ué TComponent? isso mesmo, o pai do datamodule é o mesmo pai de todos os componentes que você usa no seu sistema, mas por ele ter sua característica de um form, muitos restringe seu uso, datamodule não tem nada a vê com form, sua hierarquia é muito distante, veja a raiz até chegar em um Form.
TComponent
  |_TControl
    |_TWinControl
      |_TScrollingWinControl
        |_TCustomForm
          |_TForm
Um form precisa além dos componentes de acesso a dados e entre outros que necessários, do código de seus eventos e suas regras de negócio (regras de negócio jamais no datamodule), então se temos um datamodule para cada form o form terá só esse component a mais na memória além do que já irá precisar tendo o datamodule ou não, o que acontece no cenário 1 e 2. 

Bem, disse acima, regras de negócio jamais no datamodule, então como proceder? Simples usando padrões de projeto e criando classe com as regras negócio para cada necessidade e linkando os eventos dos componentes que estão no datamadule aos métodos criados na classe. 

Exemplo TClientDataSet para Cliente no TDatamodule, nele um evento ClienteBeforePost(Dataset: TDataSet)
type
  TClienteClassRegra = class
  public
    class procedure ClienteBeforePost(Dataset: TDataSet); 
  end; 
...

procedure TClienteClassRegra.ClienteBeforePost(Dataset: TDataSet)
begin
  // Regra de negócio aqui
end;
No TDatamudule só o código do evento, chamando o método da classe, deixando assim o datamodule limpo e a regra livre para serem usados em qualquer outro lugar quando preciso.
procedure TDataModule.ClienteBeforePost(Dataset: TDataSet)
begin
  TClienteClassRegra.ClienteBeforePost(Dataset);   
end;
E assim definindo métodos para cada evento usado, inclusive classe para eventos dos TFields como SetText, GetText, OnValidate etc..., tendo a classe, ela pode ser usada em vários datamodules, pois cada um só terá o ponteiro linkado, disparando a regra na classe.
Exemplo:
type
  TClienteFieldRegra = class
  public
    class procedure ClienteFieldNameGetText(Sender: TField; var Text: string;
      DisplayText: Boolean);
  end; 
...

procedure TDataModule.ClienteFieldNameGetText(Sender: TField; 
  var Text: string; DisplayText: Boolean);
begin
  TClienteClassRegra.ClienteFieldNameGetText(Sender, Text, DisplayText);
end;
Para melhorar ainda mais esse desacoplamento, indico o não uso de TField em Designer, crie-os em run-time, já faço isso a muitos anos, e tem algo que pode fazer isso para você de forma simples, conheça e usar o ORMBr.

segunda-feira, 17 de abril de 2017

ORMBr - Versão 1.3.3 (Abr 2017)

  • Melhoria - Implementado recurso para atualizar dados da tabela externa com relacionamento OneToOne quando a coluna chave de relacionamento for mudada.
  • Melhoria - Otimização no método Open(), para que o SELECT seja construído somente uma vez.
  • Melhoria - Refatoração nos métodos Open() e Find(), para aceitarem o parâmetro ASQL como String.
  • Melhoria - Renomeado método GetNextPacket para NextPacket.
  • Melhoria - Liberado o método NextPacket, para ser chamado pela aplicação, caso a propriedade AutoNextPacket = False;
  • Melhoria - Refatoração nos métodos DisableDataSetEvents e EnableDataSetEvents.
  • Melhoria - Grande refatoração para aumento de performance, passando a usar mais informações mapeadas do objeto e menos RTTI.
  • Correção - Ajuste feito para respeitar a paginação de registros, quando passado um comando SELECT pelo método Open() e Find() direto, não estava sendo feito paginação nenhuma.
  • Novo - Atualização do demo que não usa dataset, mostrando como criar um campo Aggregate, direto na class totalizando determinado campo.
  • Novo - Criado método FindWhere(AWhere: string), esse método adiciona a clausula WHERE ao final do comando SELECT montado, passando assim um filtro para restringir o retorno de registros do banco de dados em um TObjectList<M>
  • Novo - Criado método OpenWhere(AWhere: string), esse método adiciona a clausula WHERE ao final do comando SELECT montado, passando assim um filtro para restringir o retorno de registros do banco de dados em um IDBResultSet.
  • Novo - Criado a propriedade AutoNextPacket, para que o método NextPacket possa ser controlado pela aplicação, valor padrão é TRUE;
  • Novo - Criado interface ICommandMonitor que irá monitorar todos os comandos executado pelo ORMBr e mostrar em uma tela o que foi executado. Funcionalidade mostrada no demo na pasta ..\ORMBr\Demo\Data\FireDAC.
  • Novo - Driver TFactorySQLite para acesso nativo ao SQLite, o driver usa componente de terceiro, as units agora fazem parte do projeto ORMBr e está na pasta ..\ORMBr\Source\External\SQLite, podem ser usadas sem precisar instalar o componente na IDE, basta instânciar o componente direto na aplicação.
Exemplo :
 FDatabase := TSQLiteDatabase.Create(Self);
 FDatabase.Filename := '..\Database\database.db3';

segunda-feira, 3 de abril de 2017

ORMBr - Conhecendo Formas de Obter Dados do Database

Seja bem vindo, e ótima leitura.
Veja as possíveis formas de obter dados do Database pelo ORMBr para popular um DataSet em memória.





Declare uma variável do tipo da interface de DataSet
  var
    oMemTable: IContainerDataSet;
Instâncie a interface, aqui vou usar TFDMemTable do FireDAC, mas temos ainda TClientDataSet até a data de hoje.
  begin
    oMemTable := TContainerFDMemTable.Create(oConn, MyFDMem);
Agora vou mostrar as formas que podemos fazer a abertura para que os dados sejam capturados do banco de dados e populem o FDMemTable em memória.
begin
  // 1a Forma - Traz os dados da tabela Master do banco e popula o FDMemTable 
  // em memória.
  oMemTable.DataSet.Open;

  // 2a Forma - Traz o registro com ID = 5 e popula o FDMemTable em memória.
  oMemTable.DataSet.Open(5); 

  // 3a Forma - Você quem define o comando SELECT usando a interface ICriteria.
  oMemTable.DataSet.Open(CreateCriteria.Select.All
                                       .From('Master')
                                       .Where('master_id >= 5')
                                       .OrderBy('description'));

SAC Automação Delphi e Lazarus

SAC Automação Delphi e Lazarus
Assine nosso SAC Automação Delphi e Lazarus para ter suporte técnico especializado em desenvolvimento

Quem sou eu

Minha foto

Proprietário/Administrador de Empresa em TI (Tecsis Informática)
  • Autor dos projetos OpenSource ORMBr, e DBCBr
  • Autor dos componentes ACBrInstall, ACBrSped, ACBrPaf, ACBrInStore, ACBrDownload.

Total de visualizações

Postagem em destaque

ORMBr - Mapeamento objeto-relacional

Mapeamento objeto-relacional ( ou ORM, do inglês: Object-relational mapping ) é uma técnica de desenvolvimento utilizada para reduzir...

Todo os direitos reservados.. Tecnologia do Blogger.

Seguidores

Google+ Seguindores