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
Muito bom. E muito raro encontrar artigos sobre Data Service na comunidade, principalmente em portugues.
Parabens pela iniciativa.
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.
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