Evitando queries desnecessárias

O DataServices, por padrão, atualiza os dados de todos os clientes conectados a qualquer mudança feita nos objetos por ele gerenciados. Isto acaba gerando “queries” desnecessárias em alguns casos. Este post apresenta uma técnica que permite evitar este problema ao controlar a execução do método “fill()”.

Vamos imaginar uma aplicação distribuída em que se queira controlar o cadastro de funcionários dentro de uma empresa.
Eu, Henrique, quero procurar e alterar alguns funcionários que tenham um cargo “digitador” e, portanto, aplico um filtro passando uma string “digitador” para o método fill() do meu EmployeeAssembler. O resultado disto, por exemplo, seria um ArrayCollection de EmployeeVO populando um DataGrid.

Por sua vez, o meu amigo Rafael, que está utilizando a mesma aplicação, quer alterar outros funcionários com um cargo “analista” e da mesma forma aplica um filtro passando “analista” como parâmetro resultando em outra lista de funcionários.

Por padrão o Data Services iria executar o método fill() para cada cliente conectado naquele destination, o que poderia ser bastante custoso se considerarmos um grande numero de usuarios simultaneos. Por isso, gostaria muito que a toda mudança feita em um funcionário com cargo “digitador” não resultasse na re-execução das queries de todos os clientes conectados que não estejam vendo os mesmos funcionários que eu estou vendo. Neste exemplo, o meu amigo Rafael não deveria receber nenhuma modificação quando eu mudar algum funcionário com o cargo diferente do que ele está vendo.

Resumindo, gostaria de controlar a execução do método fill() do Data Services caso seja incluído ou alterado um registro. Temos duas possíveis soluções para isto: Uma seria usando o método refreshFill() e a outra declarando o método “fill-contais-method”. Vamos ver a primeira solução:

Nesta solução não devemos declarar o método fill() no arquivo data-management-config.xml, do Flex Data Services. Na classe EmployeeAssembler (criada para controlar a minha entidade EmployeeVO), sou obrigado a declarar o método refreshFill(). A cada modificação este método é executado antes do fill(), tornando possível o controle da execução do mesmo. Para tanto devo retornar alguma destas constantes da classe AbstractAssembler, que irão indicar se o método será executado ou não:

• DO_NOT_EXECUTE_FILL – não executa o método fill();
• EXECUTE_FILL – executa o fill();
• APPEND_TO_FILL – adiciona a mudança na lista da última execução do fill();

Por exemplo, a minha classe Assembler poderia ter a seguinte lógica no método refreshFill():

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
public int refreshFill( Object item, Collection fillParams ) {

    int returnValue;

    if (isCreate == false) {

        returnValue = DO_NOT_EXECUTE_FILL;

    } else {

        returnValue = verifyFilters(item, fillParams);

    }

    return returnValue;
}

private int verifyFilters(Object item, Collection fillParams) {

    int returnValue;

    Employee employee = (Employee) item;

    if (fillParams.size() == 1) {

        String name = (String) fillParams.get(0);

        if (employee.getName().indexOf(name) >= 0) {

            returnValue = APPEND_TO_FILL;

        } else {

            returnValue = DO_NOT_EXECUTE_FILL;
        }

    } else if (fillParams.isEmpty() == true) {

        returnValue = APPEND_TO_FILL;
    }

    return returnValue;

}

No exemplo acima, caso o item estiver sendo mudado (update), não quero que seja executado o método fill, pois todo os clientes que possuirem este item na lista já serão notificados automaticamente, independentemente da query ser executada outra vez ou não. O Data Services faz isso através do id, declarado no data-management-config.xml.

Caso o item esteja sendo criado, devo verificar se o filtro do cliente é o mesmo usado por quem criou o item. Caso positivo, devo adicionar o mesmo na lista do ultimo fill, caso contrário não farei nada.

Se o cliente não possuir filtro, é porque ele esta com todos os registros e assim devo adicionar o item à lista também.


3 comentários

  1. Daniel Passos em 2.jul.07 às 10:04 pm

    Muito bom. E muito raro encontrar artigos sobre Data Service na comunidade, principalmente em portugues.

    Parabens pela iniciativa.

  2. Alex Hubner em 3.jul.07 às 12:19 am

    Mais difícil ainda é encontrar programadores realmente preocupados com a performance da aplicação como um todo e não apenas preocupados com a sua parte do código, se ela está funcionando ou não e o resto que se dane.

  3. Fernando em 10.ago.07 às 7:14 am

    Alex, acho que os programadores no Brasil não tem recurso, não tem tempo e não tem equipes técnicas grandes o suficiente pra construir um código de boa qualidade, com uma estrutura legal.

    Isso só conseguimos fazer quando existe bastante dinheiro envolvido e bastante gente trabalhando, dando opiniões, planejando.

    Eu trabalho como programador fora do Brasil e por isso tenho essa opinião.

Deixe Seu Comentário