Artigos Canal Mais Editorial Engenharia de Software 2 - DevMedia

Curso de dbExpress e DataSnap

Parte XV – Packet Records

Neste exemplo veremos como usar o recurso de Packet Records do ClientDataSet. Configurando essa propriedade, podemos instruir ao servidor de aplicação que “empacote e envie dados por demanda”. Quando temos um grande select no servidor, podemos instruir ao DataSetProvider que vá enviando essas informações aos poucos, para otimizar o tráfego de dados. È importante notar desde já, que essa abordagem é menos escalável: é necessário manter o cursor e conexão ativos durante todo o processo.

Configure uma conexão dbExpress para o banco EMPLOYEE do Interbase. Coloque um SQLConnection apontando para essa conexão. Coloque também um SQLQuery, um DataSetProvider, um ClientDataSet, um DataSource, um DBGrid, um DBNavigator, um Memo e um SQLMonitor. Para configurar o recurso em tempo de execução, coloque também um RadioGroup, dois CheckBoxes, um SpinEdit.  

A listagem a seguir mostra como cada componente foi configurado:

 

  object DBGrid1: TDBGrid

    DataSource = DataSource1

  end

  object DBNavigator1: TDBNavigator

    DataSource = DataSource1

  end

  object SQLConnection1: TSQLConnection

    ConnectionName = 'EMPLOYEE'

    DriverName = 'Interbase'

    GetDriverFunc = 'getSQLDriverINTERBASE'

    LibraryName = 'dbexpint.dll'

    LoadParamsOnConnect = True

    LoginPrompt = False

    Params.Strings = (

      'DriverName=Interbase'

      'Database=C:\Borland\InterBase\examples\database\employee.gdb'

      'RoleName=RoleName'

      'User_Name=sysdba'

      'Password=masterkey'

      'ServerCharSet='

      'SQLDialect=3'

      'BlobSize=-1'

      'CommitRetain=False'

      'WaitOnLocks=True'

      'ErrorResourceFile='

      'LocaleCode=0000'

      'Interbase TransIsolation=ReadCommited'

      'Trim Char=False')

    VendorLib = 'gds32.dll'

    Left = 72

    Top = 232

  end

  object SQLQuery1: TSQLQuery

    SQL.Strings = (

      'select * from CUSTOMER')

    SQLConnection = SQLConnection1

  end

  object DataSetProvider1: TDataSetProvider

    DataSet = SQLQuery1

  end

  object ClientDataSet1: TClientDataSet

    ProviderName = 'DataSetProvider1'

  end

  object DataSource1: TDataSource

    DataSet = ClientDataSet1

  end

  object SQLMonitor1: TSQLMonitor

    SQLConnection = SQLConnection1

  end

 

No botão Refresh verificamos as configurações de tela e configuramos o Packet Records do ClientDataSet:

 

procedure TFrmMain.BitBtn2Click(Sender: TObject);

begin

  Memo1.Lines.Clear;

  if CheckBox1.Checked then

    ClientDataSet1.PacketRecords := SpinEdit1.Value

  else

    ClientDataSet1.PacketRecords := -1;

  ClientDataSet1.Close;

  ClientDataSet1.Open;

end;

 

No OnChange do SpinEdit também mudamos essa configuração:

 

procedure TFrmMain.SpinEdit1Change(Sender: TObject);

begin

  ClientDataSet1.PacketRecords := SpinEdit1.Value;

end;

 

No botão GetNextPacket chamamos o método de mesmo nome do ClienDataSet:

 

procedure TFrmMain.BitBtn1Click(Sender: TObject);

begin

  ClientDataSet1.GetNextPacket;

end;

 

No CheckBox com o nome de FetchOnDemand configuramos a propriedade de mesmo do ClienDataSet:

 

procedure TFrmMain.CheckBox2Click(Sender: TObject);

begin

  BitBtn1.Enabled := not CheckBox2.Checked;

  ClientDataSet1.FetchOnDemand := CheckBox2.Checked;

end;

 

No CheckBox usar PacketRecords fazemos alguns ajustes visuais:

 

procedure TFrmMain.CheckBox1Click(Sender: TObject);

var

  i : integer;

begin

  GroupBox1.Enabled := CheckBox1.Checked;

  Label1.Enabled := CheckBox1.Checked;

  SpinEdit1.Enabled := CheckBox1.Checked;

  CheckBox2.Enabled := CheckBox1.Checked;

  BitBtn1.Enabled := (CheckBox1.Checked) and not (CheckBox2.Checked);

end;

 

No evento OnLogTrace do SQLMonitor vamos monitorar a comunicação com o IB/FB para verificar quando e quais comandos estão sendo executados, jogando essas informações para um Memo:

 

procedure TFrmMain.SQLMonitor1LogTrace(Sender: TObject;

  CBInfo: pSQLTRACEDesc);

begin

  Memo1.Lines.Add(String(CBInfo.pszTrace));

end;

 

Vamos executar a aplicação e fazer alguns testes, usando diferentes configurações. Dessa forma, vamos entender exatamente como o PacketRecords funciona.

 

1 – Sem usar PacketRecords - clique no botão Refresh e veja o comportamento na figura a seguir. Todos os dados retornados pelo Select foram empacotados e jogados na memória (Data) do ClienDataSet. Nenhum recurso do servidor, incluindo conexão e cursor, fica preso. No entanto, o tempo necessário e tráfego de rede usado para transferir o packet é maior.

 

2 – Usando PacketRecords com FetchOnDemand ativado - clique no botão Refresh e veja o comportamento na figura a seguir. Configuramos o packet size como “3”, o que indica que os registros serão empacotados de 3 em três. O próprio ClientDataSet detecta quando mais registros são necessário e traz por demanda (daí o nome FetchOnDemand). Isso pode acontecer tanto por necessidade do usuário (confirme isso navegando no DBGrid para baixo) ou programaticamente (via chamadas subseqüentes ao método Next). Observe que cada Fetch envolve, lógico, uma chamada ao servidor SQL. A solução é mais otimizada para grandes resultsets, mais vai consumir mais recursos do BD, pois o cursor e conexão ficam presos aguardando novas solicitações de packet.

 

3 – Usando PacketRecords com FetchOnDemand desativado - clique no botão Refresh e veja o comportamento na figura a seguir. Configuramos o packet size como “3”, o que indica que os registros serão empacotados de 3 em três. A diferença em não usar o FetchOnDemand é que você deve solicitar novos pacotes de dados, através do método GetNextPacket do CDS (fizemos isso no botão). Faça um teste navegando até o último registro do DBGrid, observe que ele “trava” no terceiro. Clicando no botão GetNextPacket, mais três registros serão trazidos. Cada Fetch envolve, lógico, uma chamada ao servidor SQL. A solução é mais otimizada para grandes resultsets, mais vai consumir mais recursos do BD, pois o cursor e conexão ficam presos aguardando novas solicitações de packet.

 

 

Download

Esse artigo faz parte da revista Engenharia de Software 2 edição especial. Clique aqui para ler todos os artigos desta edição

 img

Editorial

 

“A indústria de software continua sentindo os efeitos da crise do software da década 80. Isto pode ser observado quando analisamos os três principais sintomas da crise do software apresentados por Pressman em 2006, a saber:

·         A produtividade não tem acompanhado a demanda por serviços;

·         A qualidade do software, em alguns sistemas, não é adequada;

·         As estimativas de prazo e custo são freqüentemente imprecisas.

 

Este último sintoma, que está associado a um dos principais problemas que a indústria de software tem enfrentado (a falta de previsibilidade de custo e prazo de projetos de software), pode levar a conseqüências desastrosas, tais como: conflitos entre o gerente do projeto e a equipe, baixa estima da equipe, entrega de software de baixa qualidade, perda de imagem da organização, e até mesmo o cancelamento do projeto. Assim, torna-se importante o investimento na implantação de um processo de estimativas efetivo, visando a melhoria da previsibilidade de custo, prazo e esforço.”

Neste contexto, a Engenharia de Software Magazine destaca nesta edição uma matéria cujo propósito é apresentar um processo de estimativas de projetos de software, aderente ao modelo CMMI, utilizando a métrica de Pontos de Função para estimar o tamanho funcional do projeto de software.

Gostaríamos de destacar também uma matéria do Professor Antônio Mendes sobre Planejamento de Projeto. Este artigo caracteriza a gestão de projetos de software, destaca sua importância e mostra como ela pode impactar diretamente no sucesso do projeto e produtividade das empresas do setor

Além destas duas matérias, nossa segunda edição traz mais sete artigos:

·         CBD x SOA: Serviços, processos de negócio e componentes que realizam os serviços

·         Visão da gerência de riscos na engenharia de software

·         Gerência de Configuração de Software: Desenvolvendo software de forma eficiente e disciplinada

·         Gestão de testes: Ferramentas Open Source e melhores práticas na gestão de testes

·         MPS.BR – Mitos e verdades a respeito de um modelo de maturidade

·         Análise Orientada a Objetos: Como chegar a um modelo OO focado em responsabilidades a partir de casos de uso

·         Desenvolvimento de Software Dirigido por Caso de Uso Parte I: Conceituando e Entendendo Caso de Uso

 

Por fim, gostaríamos de destacar que a partir desta edição a Engenharia de Software Magazine será acompanhada de 5 vídeo aulas disponibilizadas no portal da Revista. Estas aulas serão gravadas pelo corpo editorial da revista e seus articulistas e certamente agregará ainda mais conhecimento ao conteúdo disponibilizado através dos artigos. 

Desejamos uma ótima leitura!

Equipe Editorial Engenharia de Software Magazine

 

 

img

Editor

Marco Antônio Pereira Araújo

(maraujo@devmedia.com.br) É Doutorando e Mestre em Engenharia de Sistemas e Computação pela COPPE/UFRJ – Linha de Pesquisa em Engenharia de Software, Especialista em Métodos Estatísticos Computacionais e Bacharel em Matemática com Habilitação em Informática pela UFJF, Professor dos Cursos de Bacharelado em Sistemas de Informação do Centro de Ensino Superior de Juiz de Fora e da Faculdade Metodista Granbery, Analista de Sistemas da Prefeitura de Juiz de Fora. É editor da Engenharia de Software Magazine.

 

img

Editor

Eduardo Oliveira Spínola

(eduspinola@gmail.com) É Editor das revistas Engenharia de Software Magazine, SQL Magazine, WebMobile. É bacharel em Ciências da Computação pela Universidade Salvador (UNIFACS) onde atualmente cursa o mestrado em Sistemas e Computação na linha de Engenharia de Software, sendo membro do GESA (Grupo de Engenharia de Software e Aplicações).

Confira cursos de Engenharia de Software da DevMedia

Curso de introdução a UML

Curso DER conceitos e prática

Curso de introdução a Engenharia de requisitos

Leia todos artigos da série