para indicar que queremos que todos os valores sejam retirados. Essa anno- tation suporta configurações mais específicas, entretanto, invalidar todos os valores geralmente vai ser mais do que o suficiente para a sua aplicação. Vale lembrar que o atributo valuepode receber um array de nomes. Isso seria especialmente útil se tivéssemos cacheado o retorno do método que carrega um produto e o tivéssemos colocado em outra região, por exemplo.
9.3
Usando um provedor de cache mais avan-
çado
O ConcurrentMapCacheManager, como já foi citado, é uma implemen- tação de cache muito simples. Vários fatores são importantes, quando vamos colocar objetos no cache.
• Qual o tempo máximo?
• Qual o número limite de objetos?
• Qual o número limite de objetos de determinado tipo? • Qual o tempo máximo inativo?
Claro que a resposta dessas questões dependem da complexidade do pro- blema que você está querendo resolver. Para tentar cobrir algumas dessas questões, podemos usar uma implementação provida pelo Guava, uma bibli- oteca criada pelo Google com várias classes que podem ser úteis em qual- quer projeto. Siga este link:https://code.google.com/p/guava-libraries/wiki/ GuavaExplainedpara mais detalhes sobre o que é oferecido.
Para resolver o nosso problema, vamos ficar apenas com a parte de cache, fornecida pelo Guava.
@Bean
public CacheManager cacheManager() { CacheBuilder<Object, Object> builder =
CacheBuilder.newBuilder() .maximumSize(100) 140
Casa do Código Capítulo 9. Melhorando performance com Cache .expireAfterAccess(5, TimeUnit.MINUTES);
GuavaCacheManager cacheManager = new GuavaCacheManager(); cacheManager.setCacheBuilder(builder);
return cacheManager; }
A classe CacheBuilder, do próprio Guava, serve para criarmos nossa configuração de cache. Perceba que conseguimos definir alguns valores que respondem a algumas das perguntas que fizemos anteriormente. Além disso, o Spring já criou uma extensão que possui uma implementação da interface CacheManager justamente para suportar o Guava, no caso a GuavaCacheManager. Com essa mudança, saímos de um provedor bem simples de cache para um já mais completo e que, provavelmente, você vai poder usar em algum de seus projetos.
Apenas um último detalhe em relação à utilização do provedor do Guava: precisamos alterar nosso arquivo pom.xml para adicionar a extensão do Spring. <!-- cache --> <dependency> <groupId>com.google.guava</groupId> <artifactId>guava</artifactId> <version>18.0</version> </dependency> <dependency> <groupId>org.springframework</groupId> <artifactId>spring-context-support</artifactId> <version>4.1.0.RELEASE</version> </dependency>
Além das opções citadas aqui no livro, o Spring também suporta outros provedores de cache, já prontos.
• EhCache • GemFire
9.4. Conclusão Casa do Código • JSR-107, especificação do Java para padronizar as APIs de cache. Caso nenhum desses sirva para você, ainda existe a possibilidade de você implementar a interface CacheManagere plugar a sua solução.
9.4
Conclusão
Neste capítulo, vimos uma das soluções mais importantes quando estamos falando de performance de uma aplicação. Evitar o acesso ao disco ou a algum serviço remoto, pode fazer com que sua aplicação diminua drasticamente o tempo de resposta das requisições. O único ponto a que você deve ficar muito atento é em relação a quais objetos devem ir para o cache. Lembre-se sempre, quando um objeto está cacheado, você deve aceitar que seus usuários, nem que seja por um curto período de tempo, podem ver dados que não são os mais atualizados.
Capítulo 10
Respondendo mais de um
formato
Nossa aplicação, até o presente momento, só lida com requisições vindas de um navegador, só que agora vamos um pouco além do que já existe na Casa do Código. Sites de vendas muito grandes, como a Amazon e o Submarino, além de exporem os seus produtos em seus sites, fazem parcerias com outros sites para que essas outras aplicações também possam exibir seus produtos.
10.1
Expondo os dados em outros formatos
Quando falamos de integração com outras aplicações, o primeiro ponto em que temos que pensar é: qual é o formato que vamos usar para realizar a in- tegração? Atualmente, nossa aplicação só é capaz de retornar páginas para os
10.1. Expondo os dados em outros formatos Casa do Código clientes, no caso os navegadores, em HTML. Um outro tipo de cliente, hoje já muito comum, são os celulares com Android ou iOS. E como você já deve esperar, exibir dados através de HTMLpode não ser o formato ideal para ser usado nesses aparelhos.
A primeira tarefa que precisamos fazer é ter um outro método no nosso controller, que seja capaz de retornar a lista de livros em outro formato. O escolhido aqui vai ser o JSON, que é um formato muito comum no mercado. ...
public class ProductsController {
@RequestMapping(method = RequestMethod.GET,value="json") @ResponseBody
public List<Product> listJson() { return products.list(); }
}
Perceba que só adicionamos mais um método à classe
ProductsController, a única diferença foi que usamos a annota- tion @ResponseBody. Ela informa para o Spring MVC que o retorno do método é para ser usado diretamente como corpo da resposta. Caso você não use essa annotation, ele vai procurar por uma página, que é o comportamento padrão. Basta que alguém acesse o endereço /produtos/json, que o retorno já vai ser um JSON.
Talvez o leitor mais curioso esteja se perguntando: por que o retorno vai ser um JSON, onde foi que configuramos isso? Como já adicionamos a de- pendência do Jackson no nosso classpath, o Spring MVC já entende que esse é o único formato, além do HTML, cuja configuração já temos.
E se tivermos clientes que trabalhem melhor comXMLdo que comJSON? Como vamos fazer? Nesse momento, temos que ter um método para cada formato de resposta que precisamos.
Casa do Código Capítulo 10. Respondendo mais de um formato