Executar um “select” em paralelo na verdade é bem simples, mas complexo se não deter algumas informações elementares sobre o tratamento que o FireDAC dá ao isolamento de conexão.

Basicamente o processo se dá pelo isolamento da “connection” ao fazer a chamada no banco de dados, talvez aí o maior problema já que é necessário ter uma conexão individual para cada chamada ao banco.

No FireDAC esta disponível na IDE o componente TFDMonitor que é responsável em gerar um novo componente de conexão para cada chamada feita. Este é o caminho mais fácil para utilizar “multithreaded”, assunto que não irei tratar aqui já que o interessante é explorar recursos que entregue mais conteúdo a quem quer entender como o processo acontece.

em construção …. ajude a escrever este texto enviando comentários. Gratidão

Base para o texto:
Unit: Data.FireDAC.Helper
Ver: Exemplo no GIT

Criar um novo componente no Delphi é basicamente implementar algum comportamento “by code” que será executado quando for requisitado ao componente.

base
Um componente publicado na paleta de objetos da IDE permitem arrastar e soltar para os formulários entregando recursos RAD ao desenvolvedor.
O componente pode ter um comportamento visual no FORM quando herda de outro componente visual, ou não visual quando herda de um TComponent;

Exemplo

  • um componente visual: TEdit
  • componente não visual: TDatasource

estrutura de um componente
[code]
/// sample1
unit xxxx;

type
/// minha implementação
TMeuComponent = class(TComponent)
private
FAbout:string;
published
/// mostrar a propriedade no Object Inspect da IDE
property About:string read FAbout write FAbout;
end;

/// registrar o component na paleta da IDE
procedure register;

implementation
procedure register;
begin
RegisterComponents(‘MVCBr’,[TMeuComponent] );
end;
end.
[/code]

Caso o componente implemente uma interface é possível indicar qual a interface junto com a mesma declaração do novo componente:

[code]
/// sample2
unit xxxx;

type
IMeuComponent = interface
[Ctrl+G para obter um GUID]
….
end;
/// minha implementação
TMeuComponent = class(TComponent,IMeuComponent)
private
FAbout:string;
published
/// mostrar a propriedade no Object Inspect da IDE
property About:string read FAbout write FAbout;
end;

/// registrar o component na paleta da IDE
procedure register;

implementation
procedure register;
begin
RegisterComponents(‘MVCBr’,[TMeuComponent] );
end;
end.
[/code]

a pegadinha

Para componentes simples será suficiente o código de exemplo indicado. Já quando o componente encapsula outros componentes (visuais/ou não) que são ligados diretamente no FORM através de propriedades, será necessário código adicional para ajudar a IDE a retirar a ligação dos componentes quando não forem mais necessário.

vejamos um exemplo de um componente com um “link”:

[code]
///sample3
type
TDBMeuComponent = class(TComponent)
private
FDatasource:TDatasource;
published
property Datasource:TDatasource read FDatasource write FDatasource;
end;
[/code]

escrevendo para a IDE

Neste caso (sample3) a propriedade Datasource permitirá que em tempo de design seja ligado um TDatasource na propriedade Datasource; A ligação do componente ocorre visualmente na IDE (ligando as propriedade), o problema ocorre neste ponto em razão da IDE não saber lidar com o desfazimento desta ligação. Como a IDE não sabe qual o momento correto em desfazer a ligação, é necessário indicar esta situação no código através do método “Notification” como segue.

[code]
///sample4
type

TDBMeuComponent = class(TComponent)
private
FDatasource: TDatasource;
protected
procedure Notification(AComponent: TComponent;
AOperation: TOperation); override;
published
property Datasource: TDatasource read FDatasource write FDatasource;
end;

{ TDBMeuComponent }

procedure TDBMeuComponent.Notification(AComponent: TComponent;
AOperation: TOperation);
begin
inherited;
/// retira o link do datasource
if AComponent.Equals(FDatasource) and (AOperation = TOperation.opRemove) then
FDatasource := nil;
end;
[/code]

Importante !!!
A maioria dos BUGs de IDE em tempo de Design ocorre pela uso inadequado do Notification, então é bom ficar atento a este ponto obrigatório para aqueles que pensam em implementar novos componentes para a IDE do Delphi.

Exemplo Completo

As units MVCBr.MongoModel e MVCBr.FDMongoDB implementam acesso as coleções MongoDB diretamente em um componente TFDMemTable abrindo os dados e enviando as alterações de volta no servidor do MongoDB.

base
O acesso ao MongoDB implementado como um Model do MVC, faz acesso direto a biblioteca MongoWire e está pronto para Auth3 presente na versão mais recente do MongoDB.
Dado a facilidade de uso do MongoDB que não exige um “schema” para as tabelas é uma boa solução em ambiente que requeira compartilhamento de dados e flexibilidade na mudança de estrutura dos documentos, justificando esforço adicional para implementar soluções RAD que de velocidade ao “coder”.

elementar
Bancos NoSQL como MongoDB não são acessados com comandos tradicionais como no ambiente SQL. É uma nova fronteira em armazenamento de dados que evoluiu muito recentemente, ainda que há um movimento para retroceder para modelos Cliente/Servidor mais tradicional adicionado de boas experiências com aprendizagem NoSQL como é o caso de TimescaleDB que faz uma mescla de recursos do Postgres e novos recursos até então visto somente nos bancos NoSQL – Novos estudos pela frente.

componentes

MongoConnection
Provê conectividade com o MongoDB.


MongoDataset
Um Dataset para obter os dados do servidor. Onde: CollectionName representa a tabela (coleção) que armazena os documentos; KeyFields é uma lista de colunas (seprado por “;” que indica a “where” a ser submetido ao servidor quando faz um “update” ou “delete”;

Exemplo no Git

Veja o Mongo Tips do amigo Thulio Bittencourt

Singleton – este é um cara engraçado. Não aceita sobrecarga nem substituição – fecha em sí e não abre para estender seu recursos. Maaasss… ele é o fino em compartilhar os seus atributos. Sempre que alguém pergunta por ele, a resposta é a sempre a mesma – inflexível e sem surpresas.

base
Singleton é uma instância global a ser evitada, mas quando não tem outra saída – é um bom parceiro.

elementar meu caro
Sendo um Singleton uma instância global, basta criar a instância uma única vez e sair usando – controlar o momento em que um Singleton pode ser liberado da memória pode ser um bom desafio. Em geral a instância é criado em algum momento do código e sua liberação ocorrerá ao finalizar a aplicação, mantendo-o carregado na memória durante o tempo de vida do aplicativo.

quando usar
Sempre que for necessário uma instância que faça controle de outras instâncias, o Singleton será bem útil. O Delphi possui alguns deles como exemplo o “Application”, uma instância que existe por toda a vida ativa do aplicativo, criado ao entrar e liberado somente quando é encerrado.
O MVCBr possui um subtitulo ao “application” o “ApplicationController”. ApplicationController é uma instância única que mantém uma pilha de “controllers” aberto no aplicativo, aqueles que estão instanciados.

limitações

Quando o desejo é atribuir um variável única para o um objeto específico e suas herança, o uso do Singleton é bastante “simples” – basca criar um “Class Var” para a instância a controlar.
Se de outro lado, se o desejo for permitir herança e cada herança tem o seu próprio Singleton então “Class Var”* não irá resolver a classe base precisa implementar mecanismos mais espertos (*a class var pertencerá sempre ao pai e não permite nova cópia aos filhos).

curiosidades
O TMVCBrSingleton faz uso de outros dois patterns:
LazyLoad – quando cria a instância para a classe alvo somente quando ela for necessária (ver invoke);
Adpater – exporta a classe base por default sem necessidade de fazer referências indiretas ( ver ..factory.mudarFlag(true) .. )

Uma classe que permite transferir um Singleton individual aos filhos
Unit: MVCBr.Patterns.Singleton
O Singleton do MVCBr implementa uma interface de adaptadora para a interface IMVCBrSingleton como já vimos antes (ver mais: princípio adaptador para interface ). Como uma classe adaptadora, é possível aplicar o “generics” para retornar o próprio singleton adaptado pela classe, vejamos:

[code]
unit singleton.MinhaClasse;

interface

uses MVCBr.Patterns.singleton;

type

/// minha classe alvo
TMinhaClasseAlvo = class(TObject)
public
function mudarFlag(AValue: Boolean): Integer;
end;

/// criando uma classe factory filha
TMinhaClasseFactory = class(TMVCBrSingleton<TMinhaClasseAlvo>)
end;

var
MinhaClasseFactory: IMVCBrSingleton<TMinhaClasseAlvo>;

implementation

{ TMinhaClasseAlvo }
function TMinhaClasseAlvo.mudarFlag(AValue: Boolean): Integer;
begin
result := ord(AValue);
end;

initialization
MinhaClasseFactory := TMinhaClasseFactory.new() ;
end.
[/code]

caso 1
Para criar uma instância local da interface – não parece lógico, somente para ilustrar, podemos fazer:
[code]
var
MinhaClasseFactory: IMVCBrSingleton<TMinhaClasseAlvo>;
begin
/// LOCAL
/// criando a classe factory para singleton
MinhaClasseFactory := TMVCBrSingleton<TMinhaClasseAlvo>.New();
showMessage(MinhaClasseFactory.mudarFlag(true).ToString);

[/code]

caso 2
Usando a classe factory que implementa uma herança de TMVCBrSingleton:
[code]
// usa o singleton
showMessage( MinhaClasseFactory.mudarFlag(false).toString);
[/code]

Um dia vi um programador tentando usar um componente VCL comum do Delphi que não tinha um correspondente DB para ele. Olhando a ginástica necessária para o componente responder a movimentações do Dataset, então lembrei quando estava aprendendo Delphi a uns 20 anos. O mais sensato é criar um novo componente DB para o mesmo.

base
Um componente DB é um componente de uso geral que responde a eventos existentes no TDatasource. O TDatasource emite uma chamada para o evento – no lado do componente, ele trata o evento e atualiza a visualização para o usuário.

elementar meu caro
Para receber evento, um componente DB deve responder aos eventos emitidos pelo TDatasource e fazer o ligação com a coluna da tabela que ao qual esta associado. Assim sendo, o componente DB irá expor uma ligação para o TDatasource (Datasource) e outro para o coluna desejada (Field);

o exemplo
Sabe aquele componente encontrados nos celulares ON/OFF, que tal criar um componente VCL DB para ele. O componente que executa esta funcionalidade na VCL é o TToggleSwitch, então vamos torná-lo um “dataware”.

usando unit: MVCBr.DataControl
Para facilitar a criação dos diversos componentes DB existentes no MVCBr – é feito uso do componente TMVCBrDataControl que entrega o mecanismo básico a todo componente DB. Ele que faz a ligação com evento “OnChange” do Datasource com a base do novo componente, vejamos como ficou…

[code]

TDBToggleSwitch = class(TToggleSwitch)
private

published
property ValueTrue: string read FValueTrue write SetValueTrue;
property ValueFalse: string read FValueFalse write SetValueFalse;
property DataField: string read GetDataField write SetDataField;
property Datasource: TDatasource read GetDatasource write SetDatasource;
end;

[/code]

as propriedades
Datasource e DataField são comuns aos componentes DB para ligar TDatasource e coluna da tabela;
ValueTrue: indicar qual o valor encontrado na tabela que indica ON;
ValueFalse: indicar qual o valor encontrado na tabela que indica OFF;

Unit completa no GIT

O uso de “Template” na IDE do Delphi proporciona melhoria de produtividade a medida que reduz digitação de rotinas repetitivas.
Ainda a pouco tempo abordei sobre o uso de Template de MVCBr e ORMBr aqui no blog – hoje vamos ver alguns “templates” disponíveis para uso com MVCBr.

base
Os “templates” de MVCBr encontram-se na pasta .\templates; A instalação dos templates é basicamente copiar os arquivos XML para a pasta padrão de templates do Delphi como já foi tratado no “artigo anterior sobre templates“.

elementar meu caro
Copiando os arquivo XML para a pasta padrão, o Delphi irá disponibilizar as macros de chamada para os templates utilizando o atalho: CTRL+J ou ainda pelo uso da sequência de palavras que identificam um template em particular.

base para acesso aos templates
mv – macros para views
mc – macros para controller
mm – macros para model
mo – macros para Observables

vamos a lista de macros para os templates (CTRL+J)

VIEWS
mv.conv – utilizado para converter um FORM já existente em um componente para MVCBr (criar interfaces para View, Controller e Classe Controller);
mv.docommand – criar método DoCommand (um override) a ser adicionado para VIEWs que queira receber notificação de EVENTS do Observer de controle interno ao framework;
mv.form – criar as assinaturas de classe e interfaces que permite converte um FORM para VIEW (mais enxuto em relação ao mv.conv);
mv.update – criar método UPDATE (um override) para views que receberam eventos UPDATE enviado pelo observer genérico de usuário;
mv.uses – criar uma lista de dependências de uses para VIEWs (auxiliar de conversão de FORMs que já existem);

Controlles
mc.addmodel – adiciona modelo de exemplo para adicionar um MODEL ao controller – utilizado no Create do Controller ou CreateModules;
mc.factory – cria a assinatura para um controller, útil para criar controllers independentes ou para conversão de código legado;
mc.fdconnection – cria uma sequência de código para o controller que gerar conexão de banco dados FireDAC;
mc.init – cria uma sequência de geração de INIT que permite inserir um TFormFactory em um controller;
mc.initialization – cria a chamada de registro do controller para a lista de controllers disponível ao aplicativo;
mc.interface – cria uma sequência para gerar uma interface para o controller;

Models
mm.creator – cria uma UNIT exemplo de geração de um MODEL genérico;
mm.ormbr.fd – cria uma sequência de integração de FireDAC Modelo do ORMBr com Model MVCBr;
mm.ormbr.sqlite – cria uma sequência de integração com SQLite deo ORMBr com Model MVCBr;
mm.ormbr.createGetTable – cria uma sequência para função GetTable para ORMBr;
mm.ormbrfb.table – cria conjunto para gerar acesso Firebird de integração de ORMBr com Model MVCBr.

Observable
mo.subscribe – criar um serviço de Observer assinando um determinado evento – como se fosse um “callback”;
mo.unsubscribe – remove o serviço do Observer;

GIT com a lista completa dos XML utilizados

Impressionante o número de vezes que precisamos copiar os valores de atributos de um objeto para outro ou simplesmente criar um novo com as mesmas propriedades.
Conhecendo a classe TMVCBrPrototype notamos o poder de RTTI combinado com Generics nos permite facilitar o trabalho sem precisar digitar todos aquelas propriedades envolvendo os dois objetos.

base
Usando Generics para passar o tipo de classe a ser manipulado e com RTTI descobrimos quais os atributos desta classe… agora é só os valores de uma para o outro.

elementar meu caro
Uso de Generics tem por finalidade facilitar o RTTI pegar quais os atributos a serem copiados do objeto alvo. Para que a cópia ocorra, o objeto de origem e de destino precisam possuir o mesmo nome para o atributo. O ideal é que ambos possuam a mesma tipagem, ainda que não seja obrigatório.

[code]
TMVCBrPrototype = Class(TInterfacedObject, IMVCBrPrototype)
public
class procedure Copy<T: Class>(ASource: T; ATarget: T); static;
class function Clone<T: Class>(ASource: T): T; static;
class function New<T: Class>: T; static;
end;

// Como copiar de B para A

var B,A : TMinhaClasse;


se: B := TMinhaClasse.create;
B.nome := ‘x’;

clone:
A := TMVCBrPrototype.Clone<TMinhaClasse>(B); /// Cria A e copia B para A

para copiar (requer que A e B já estejam criados):
TMVCBrPrototype.Copy<TMinhaClasse>(B,A); /// copia B para A

[/code]

TMVCBrPrototype

Inspecionando o código MVCBr irá notar que o uso de interface é predominante às diversas classes do framework.

base
Uma variável tipada por uma interface é diferente de uma variável “object” por estabelecer um independência entre o objeto e a implementação de classe do objeto. Como é comum, se diz que a interface é um contrato estabelecido entre o cliente e o fornecedor – No delphi pascal, o objeto representado por uma instância não requer o tradicional FREE para liberar o objeto. A linguagem estabelece um contador incremental de referência para a instância a cada chamada e o decrementa a medida que não seja necessária, quando alcança um “count=0” o objeto é liberado da memória.

elementar meu caro
Se o objeto é liberado de forma automática “gerenciada pelo gerenciador”, então não é necessário FREE ou DisposeOf. Em alguns trechos de código é comum encontrar uma atribuição NIL para forçar o decremento do contador de referência – com isto força a liberação da instância da memória mesmo antes de terminar o execução do trecho de código.

Quando usar Create()
O uso do “Create(..)” permite criação da classe pascal nativa “SEM” fazer uso da interface. Nestes casos a liberação do objeto da memória se dará fazendo uma chamada FREE ou DisposeOf para o mesmo;

Usando New(..)
Em geral, o uso do NEW é implícito o desejo em obter uma instância representado pela interface que a classe implementa. Como uma interface, a instância dispensa o Free ou DisposeOf, fica a cargo do contador de referência retirar o objeto da memória.

Posso converter um Objeto em uma representação Interface ?

Se o objeto em questão implementa uma interface a resposta será SIM. Toda classe que implementa uma interface pode ser criada com CREATE e atribuído a uma variável tipada para a interface que implementa. Neste caso o gerenciamento de memória é feito pela representação “Interface” e não requer Free ou DisposeOf;

Exemplo:

[code]
type
IMinhaClasse = interface
[…]
end;
TMinhaClasse = class(TInterfacedOjbect, IMinhaClasse)
end;

….

var LMinhaClasse : IMinhaClasse;

LMinhaClasse := TMinhaClasse.create;

[/code]

No caso “LMinhaClasse” não requer Free nem mesmo DisposeOf, já que foi tipada por uma interface.

Ver também – Um Adapter Interfaced para qualquer objeto

Precisa notificar o usuário sobre algum evento?
Então você precisa de Windows Notification na sua aplicação.

base
No Windows 10 está disponível o envio de mensagens para a bandeja do windows alertando sobre alguma ocorrência.

elementar meu caro
Usar a notificação do windows é bastante simples, com a ajuda de um model do MVCBr que se encontra na pasta \AdIN\Windows base instanciar o “model” e sair utilizando – se a utilização é eventual, nem mesmo instanciar será necessário;

Unit: WinNotification.Model, WinNotification.Model.Interf;
[code]

/// declaração da classe
TWinNotificationModel

class function Notify(const AName: String; const ASubject: String;
const AMessage: String): boolean;
end;

/// enviando mensagens para o windows
TWinNotificationModel.Notify(‘Ola Windows’,
‘Horário Visita se aproximando’,’Não esqueça de sair para a visita’);

[/code]

Código de Exemplo

Tenho um objeto implementado utilizando uma herança nativa da DELPHI e gostaria de fazer uso de INTERFACE para este objeto sem precisar implementar uma nova classe.

base
Um patterns adapter objetiva gerar um adaptador que recebe um objeto externo e implementa novas funcionalidade.

elementar meu caro
Não estamos falando de herança, mas de um adaptador ao objeto que adiciona funcionalidade para o qual não foi desenhado originalmente.
Destaco como o adapter responde como se fosse o próprio objeto expondo procedures, funções e atributos diretos sem fazer CAST dos mesmos.

Unit: MVCBr.Patterns.Adapter;

[code]
uses MVCBr.Patterns.Adapter;

Type
// objeto base a ser adaptado
TMeuObjeto = Class(TObject)
public
texto:string;
End;

procedure TForm85.FormCreate(Sender: TObject);
var
LAdapter : IMVCBrAdapter<TMeuObjeto>;
begin

LAdapter := TMVCBrAdapter<TMeuObjeto>.create(nil);
// atribuir valor
LAdapter.texto := ‘texto de exemplo’;

// pegando o valor do objeto
ShowMessage( LAdapter.texto );

end;
[/code]