Um conhecimento só é válido quando compartilhado.

segunda-feira, 31 de julho de 2017

ORMBr - ORM Fácita a Programação Orientada a Objetos?

Recebi uma pergunta esses dias pertinente a ajudar a quem só se houve falar na sigla ORM, e não sabe qual o real beneficio de se utilizar um ORM no seu dia dia.
A pergunta foi "O objetivo principal do ORMBr é fácilitar a programação Orientada a Objetos?"
Então resolvi deixar descrito aqui no meu blog a resposta, ficando assim publico para que todos que tenham essa dúvida possa pelo ao menos ficar mais informado sobre para que aderir um ORM em seus projetos.
Resposta: Na verdade eu considero que não, vou falar aqui o ORMBr e não dos ORMs no geral.
O ORMBr por exemplo te ajuda automatizando processos que você teria que escrever para gerenciamento de manipulação de dados manualmente.

Exemplos:
* Criar Tabelas, Fk, Pk, Indexe no banco,  o ORMBr cria.
* Criar os TFields nos Datasets em designer, não precisa, pois o ORMBr cria automaticamente para você, então não precisa fazer isso manualmente.
* Parametrizar todos os TFields em Designer, não precisa, pois o ORMBr parametriza para você com base na classe modelo, não precisa fazer isso manual
* Escrever os comandos SQL para abrir os dados e fazer um CRUD em uma tabela, não precisa, pois o ORMBr monta o SQL para você e faz todo o CRUD com base na classe modelo.
* Linkar os componentes mestre-detalhe para o gerenciamento de abertura, fechamento etc, não precisa, pois o ORMBr faz isso automaticamente para você.
* Escrever comandos SQL, da quais muitas das vezes suja seu código, não precisa, o ORMBr tem a interface de classe ICriteria, que monta comando SQL usando POO.
* Te da possibilidade e facilidade do seu sistema ser multi-banco de dados.

Bom acho que está de bom tamanho, além de vários outros recursos.
Agora isso independente se irá desenvolver usando POO, pois com o ORMBr você pode trabalhar usando DataSet tendo todos os recursos que já se conhece hoje com os componentes dataware, ou optar por trabalhar buscando o máximo do POO, tratando e buscando dados direto por objeto do tipo e lista de objetos.

ORMBr - Driver de Acessoa a Dados UniDAC

Dar tempo ao tempo é algo complicado quando estamos esperando ansiosamente alguma coisa, mas o que importa é vermos acontecer no dia a dia e dar um passo de cada vez. O ORMBr deu mais um passo importante nesses dias, e um deles foi a doação do Marcos Nielsen ao projeto que foi o Driver de acesso a dados via UniDAC somando assim mais um Engine de acesso a dados a galeria, agora são eles:
  1. FireDAC 
  2. DBExpress 
  3. Zeos 
  4. ADO 
  5. AbsoluteDB 
  6. SQLite Nativo 
  7. UniDAC 

Deixo aqui em nome do Projeto ORMBr o agradecimento a todos que estão colaborando, tanto usando, reportando situações, contribuindo, até mesmo só olhando, meu MUITO Obrigado.

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.

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