O gerenciamento de mem\u00f3ria do DataSnap \u00e9 muito\u00a0poderoso e\u00a0uma caracter\u00edstica chave\u00a0para a implementa\u00e7\u00e3o de cache.\u00a0Imagine\u00a0o cen\u00e1rio onde a aplica\u00e7\u00e3o cliente solicita os mesmos dados milhares de vezes durante o dia, certamente teremos que tocar o banco de dados a cada solicita\u00e7\u00e3o. Vamos supor que\u00a0esses dados\u00a0n\u00e3o\u00a0mudam com muita\u00a0freq\u00fc\u00eancia, por exemplo: tabela de pa\u00edses, estados ou\u00a0cidades.<\/p>\n
Quando implementamos cache para este\u00a0cen\u00e1rio, a primeira solicita\u00e7\u00e3o obt\u00e9m os dados a partir do banco de dados e os mant\u00e9m em mem\u00f4ria, a partir da segunda solicita\u00e7\u00e3o o servidor de aplica\u00e7\u00e3o ir\u00e1 buscar estes dados em mem\u00f3ria e retornar para a aplica\u00e7\u00e3o cliente, em outra palavras a aplica\u00e7\u00e3o tocou o\u00a0banco de dados apenas uma \u00fanica vez.<\/p>\n
A combina\u00e7\u00e3o\u00a0entre o gerenciamento de mem\u00f3ria do DataSnap, DBXReader e ClientDataSet\u00a0\u00e9 o que\u00a0voc\u00ea\u00a0precisa para implementar\u00a0uma solu\u00e7\u00e3o\u00a0de cache.<\/p>\n
O gerenciamento\u00a0de mem\u00f3ria do DataSnap\u00a0\u00e9\u00a0definido atrav\u00e9s do componente\u00a0DSServerClass e sua respectiva propriedade LifeCycle,\u00a0que\u00a0voc\u00ea pode ser definida como:<\/p>\n
Vamos ver como podemos implementar uma solu\u00e7\u00e3o de cache usando o cen\u00e1rio onde terei que armazenar uma lista de estados, esta informa\u00e7\u00e3o est\u00e1 na tabela de STATE.<\/p>\n
A minha classe no servidor (ServerClass) foi criada a partir de um DSServerModule e se chama TDMDataSet5, cont\u00e9m dois m\u00e9todos privados (private) e um p\u00fablico (public), que s\u00e3o:<\/p>\n
private\r\n function GetRecords(Fields, Table: String): TDBXReader;\r\n function GetData(Cds : TClientDataSet; Fields, Table: String) : TDBXReader;\r\npublic\r\n function GetState: TDBXReader;<\/pre>\nO m\u00e9todo GetRecords ir\u00e1 consultar o banco de dados e retornar os registros como um DBXReader, este m\u00e9todo n\u00e3o implementa nenhuma l\u00f3gica para verificar se o cache j\u00e1 est\u00e1 preenchido.<\/p>\n
function TDMDataSet5.GetRecords(Fields, Table: String): TDBXReader;\r\nvar\r\n cmd: TDBXCommand;\r\nbegin\r\n\r\n cmd := DMServerContainer.GetConnection.DBXConnection.CreateCommand;\r\n try\r\n cmd.Text := 'Select ' + Fields + ' from ' + Table;\r\n Result := cmd.ExecuteQuery;\r\n except\r\n raise;\r\n end;\r\nend;<\/pre>\nComo o DBXReader \u00e9 unidirecional n\u00e3o podemos manter os dados em mem\u00f3ria, a solu\u00e7\u00e3o para isso \u00e9 copiar os dados e mant\u00ea-los em um ClientDataSet.<\/p>\n
GetData \u00e9 um m\u00e9todo interno respons\u00e1vel por criar, manter e retornar os dados como DBXReader.<\/p>\n
Conforme a implementa\u00e7\u00e3o abaixo o m\u00e9todo ir\u00e1 obter os dados a partir do banco de dados (GetRecords) somente se o ClientDataSet n\u00e3o est\u00e1 ativo, em outras palavras n\u00f3s nunca tivemos os dados em cache e somente iremos executar este c\u00f3digo uma \u00fanica vez. Ap\u00f3s o bloco do IF a classe TDBXDataSetReader ir\u00e1 copiar os dados do ClientDataSet para um DBXReader e retorn\u00e1-lo.<\/p>\n
function TDMDataSet5.GetData(Cds: TClientDataSet; Fields, Table: String): TDBXReader;\r\nvar\r\n Reader : TDBXReader;\r\nbegin\r\n if not Cds.Active then \/\/ Not active means, never move the data to ClientDataSet \u2013 no cache\r\n begin\r\n Reader := GetRecords(Fields, Table);\r\n TDBXDataSetReader.CopyReaderToClientDataSet( Reader, Cds );\r\n Reader.Free;\r\n Cds.Open;\r\n end;\r\n\r\n Result := TDBXDataSetReader.Create(Cds, False (* InstanceOwner *) );\r\nend;<\/pre>\nVoc\u00ea pode estar se perguntando por que estou copiando os dados do ClientDataSet para DBXReader e n\u00e3o retornando diretamente o ClientDataSet, duas raz\u00f5es:<\/p>\n
Um ponto importante, o DSServerModule TDMDataSet5 ir\u00e1 gerenciar o cache, se o LifeCycle para esta classe for definido como server isso ir\u00e1 significar uma \u00fanica inst\u00e2ncia do cache para todos os clientes, podemos chamar isso de “cache global”, caso defina como Session estaremos criando um cache para cada cliente conectado ao servidor.<\/p>\n
Caso a sua aplica\u00e7\u00e3o cliente utilize o DBXClient ir\u00e1 receber um DBXReader a partir da execu\u00e7\u00e3o do server method, a partir dai \u00e9 sua responsabilidade decidir o que fazer com os dados, mas sendo necess\u00e1rio conectar estes dados a componentes data-aware ser\u00e1 necess\u00e1rio copiar os dados do DBXReader para um ClientDataSet, o m\u00e9todo TDBXDataSetReader.CopyReaderToClientDataSet \u00e9 a solu\u00e7\u00e3o pra isso.<\/p>\n
TDBXDataSetReader.CopyReaderToClientDataSet(Reader, CDSCity);<\/pre>\nSe algum dados relacionado com a tabela State mudar ser\u00e1 necess\u00e1rio implementar um server method para atualizar os dados. Al\u00e9m disso, ao definir o LifeCycle como Server o cache ser\u00e1 destru\u00eddo no momento que o servidor parar (Stop), mas se utilizamos o LifeCycle Session o cache ser\u00e1 destru\u00eddo no momento em que a aplica\u00e7\u00e3o cliente se desconecta do server.<\/p>\n
Usando esta t\u00e9cnica voc\u00ea garante que o cache no servidor n\u00e3o depende da implementa\u00e7\u00e3o do lado cliente, al\u00e9m disso quero lembrar que essa solu\u00e7\u00e3o ir\u00e1 funcionar como DataSnap Servers, se voc\u00ea implementou o server usando DataSnap REST Interface voc\u00ea n\u00e3o ter\u00e1 cache, porque cada solicita\u00e7\u00e3o ao server funciona como o lifecycle invocation.<\/p>\n
Este \u00e9 um exemplo realista que explica como implementar cache em servidores DataSnap usando dados a partir de um banco de dados como exemplo, al\u00e9m disso, voc\u00ea aprendeu como mover dados de\/para ClientDataSet de\/para DBXReader.<\/p>\n