Um conhecimento só é válido quando compartilhado.

quarta-feira, 23 de novembro de 2016

ORMBr - Conhecendo o Outro Lado

Seja bem vindo, e ótima leitura. 
O combustível do ORMBr sempre será as classes modelos, e para que tenhamos alto desempenho, precisamos conhecer o que adicionar a esses modelos para que tenhamos sincronização com nosso banco de dados.
Apresento aqui para vocês as correspondências entre os tipos usados pelo ORMBr e os tipos criados no seu banco dados já existente.



procedure TFieldTypeRegister.GetFieldTypeDefinition(AColumn: TColumnMIK);
begin
  case AColumn.FieldType of
    ftByte, ftShortint, ftSmallint, ftWord:
    begin
      AColumn.TypeName := 'SMALLINT';
    end;
    ftInteger, ftLongWord:
    begin
      if      FDriverName = dnMSSQL then AColumn.TypeName := 'INT'
      else if FDriverName = dnMySQL then AColumn.TypeName := 'INT'
      else                               AColumn.TypeName := 'INTEGER';
    end;
    ftLargeint:      AColumn.TypeName := 'NUMERIC(%l)';
    ftString:        AColumn.TypeName := 'VARCHAR(%l)';
    ftWideString:    AColumn.TypeName := 'NVARCHAR(%l)';
    ftFixedChar:     AColumn.TypeName := 'CHAR(%l)';
    ftFixedWideChar: AColumn.TypeName := 'NCHAR(%l)';
    ftDate:          AColumn.TypeName := 'DATE';
    ftTime:          AColumn.TypeName := 'TIME';
    ftDateTime:      AColumn.TypeName := 'DATETIME';
    ftTimeStamp:     AColumn.TypeName := 'TIMESTAMP';
    ftFloat:
    begin
      if      FDriverName = dnMSSQL      then AColumn.TypeName := 'FLOAT'
      else if FDriverName = dnMySQL      then AColumn.TypeName := 'FLOAT'
      else if FDriverName = dnPostgreSQL then AColumn.TypeName := 'NUMERIC(%p,%s)'
      else                                    AColumn.TypeName := 'DECIMAL(%p,%s)';
    end;
    ftSingle:        AColumn.TypeName := 'REAL';
    ftExtended:
    begin
      if      FDriverName = dnMSSQL then AColumn.TypeName := 'DOUBLE'
      else if FDriverName = dnMySQL then AColumn.TypeName := 'DOUBLE'
      else                               AColumn.TypeName := 'DOUBLE PRECISION';
    end;
    ftCurrency:
    begin
      if      FDriverName = dnMSSQL      then AColumn.TypeName := 'MONEY'
      else if FDriverName = dnMySQL      then AColumn.TypeName := 'DECIMAL(%p,%s)'
      else                                    AColumn.TypeName := 'NUMERIC(%p,%s)';
    end;
    ftBCD, ftFMTBcd:
    begin
      if      FDriverName = dnPostgreSQL then AColumn.TypeName := 'MONEY'
      else if FDriverName = dnMSSQL      then AColumn.TypeName := 'MONEY'
      else                                    AColumn.TypeName := 'DECIMAL(%p,%s)';
    end;
    ftMemo:
    begin
      if FDriverName = dnFirebird then AColumn.TypeName := 'BLOB SUB_TYPE TEXT'
      else                             AColumn.TypeName := 'LOGBLOB';
    end;
    ftWideMemo, ftBlob:
    begin
      if FDriverName = dnFirebird then AColumn.TypeName := 'BLOB SUB_TYPE TEXT'
      else                             AColumn.TypeName := 'TEXT';
    end;
  else
    raise Exception.Create('Tipo da coluna definida, não existe no ORMBr.');
  end;
end;
Dependendo do tipo definido na propriedade da sua classe modelo, o ORMBr irá identificar o tipo do campos no seu banco de dados, exemplo, se definirmos a propriedade do tipo ftWideMemo ou ftBlob, o ORMBr irá identificar que no seu banco dados a coluna é BLOB SUB_TYPE TEXT no caso o banco seja Firebird caso contrário irá identificar como TEXT para os demais bancos. 
Vemos aqui que o tipo definido no ORMBr, poderá se comportar diferente dependendo do banco usado, então pessoal atenção a esse código, qualquer situação adversa me comunique, pois acredito que não pensei em todas as situações e tipos.

ORMBr - Ao Usar, Perdemos em Performance?


Muitos pensam que usar o ORMBr perderia performance, gente o ORMBr trabalho com duas linhas de frente para vocês.
1a ) Ele fará de forma SUPER simples TUDO o que você teria que fazer manual, como SELECT, Adicionar TFields e configurar um a um, gerenciar abertura de subtabelas em mestre-detalhe, TUDO isso passa a ser automatizado.
2a) Ele fará de forma SURPER simples tudo o que os componentes DataSet já faz, pois o que você achar que um TFDQuery faz, quando você alimenta os TFields dele, em seguida dispara um Post e um ApplyUpdate?

Simplesmente montam o comando SQL internamente e mandam para o banco, é exatamente o que o ORMBr faz também.

Se é assim que funciona, como podemos perder performance ?

ORMBr - TFields em Runtime

Em 2006 palestrei na Borcon e minha palestra foi sobre Multicamadas com Multibancos, na época só conseguia aplicar multibancos através de uma técnica criada por mim, que foi a criação de TFields em runtime. A Criação de TFields em Designer além de ser um CAUS para manutenções futuras em projetos, me trazia um problema de incompatibilidade entre os tipos de TFields que o Delphi criava para bancos diferentes, exemplo o tipo data, e té hoje isso acontece, só com a aquisição do FireDAC passou a ter um recurso nativo de mapeamento de tipos para os TFields, criados em designer, recurso esse que tem a mesma finalidade da que criei a mais de 10 anos atrás, resolver incompatibilidade de tipos em bancos diferentes. Porém a técnica usada por mim, elimina ainda outras situações como a manutenções futuras no projeto, mas que manutenções são essas que você diz Isaque? Se criar um campo no banco VARCHAR(10) em designer será criado um TField do tipo TStringField de size 10, esse TField pode ter sido adicionados em vários pontos do meu projeto, tela de cadastro, consultas etc..., se algum dia eu precisar mudar o tamanho desse campo no banco para 15, terá que lembrar todos os pontos do meu sistema que adicionou o TField para esse campo, caso contrário, mesmo no banco ele tendo tamanho 15, o delphi irá limitar a digitação em 10, esse é um dos exemplos simples, existem outras. Com a técnica de criar TFields em runtime, esse problema é TOTALMENTE resolvido, pois o TField será criado com base no campo atual do banco, sendo criado sempre de forma atual. Com o nascimento do ORMBr, isso ficou bem mais simples, pois além das grandes vantagens em agilidade que o ORMBr traz, ele trata, cria e configura cada TField em runtime, isso tudo com base no modelo, vejamos como podemos definir isso no modelo do ORMBr:
[Column('price', ftFloat, 18, 3)]
[Dictionary('Preço Unitário','Mensagem de validação','0','#,###,##0.00','',
taRightJustify)]
property price: Double Index 4 read Fprice write Fprice;
Vejamos os atributos:
Column : Informo o nome do campo, o tipo que quero e tamanho, pronto o ORMBr faz o resto
Dictionary : Informo o DisplayLabel, Mensagem de validação, Valor Default, DisplayFormat, EditMask, e o alinhamento.

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