Category Archives: Spring

O que muda no Spring 4.0?

thumb_beta_spring_largeComo escrevi um livro sobre o Spring Framework, não é raro que eu receba perguntas pelas redes sociais a respeito da versão 4.0. Meu livro ainda trata da versão 3.2, então aquilo que disse nele ainda é válido? Resposta rápida: em 100% dos casos, sim.

As mudanças superficiais no Spring são raras: se seu projeto é baseado na versão 3.2 do framework, a migração para o 4.0 é muito tranquila. Só é necessário alterar as dependências do seu projeto para a nova versão na esmagadora maioria das vezes. Neste post irei falar sobre as mudanças que considero serem as mais importantes.

(não sabe o que é o Spring Framework? Eu tenho um guia gratuito que pode te ajudar. Clique aqui!)

Pivotal entra em cena

Este é o primeiro grande release do Spring sob a supervisão da Pivotal. Se havia receio a respeito da competência desta nova empresa, este se transformou em alegria, pois o trabalho que fizeram foi simplesmente fantástico!

Um dos principais objetivos da empresa foi melhorar a experiência de início de projeto com o Spring, então reformularam completamente o site oficial (http://www.spring.io) . As mudanças vão muito além do layout: incluíram uma série de guias que ajudam os desenvolvedores a iniciarem da maneira mais rápida possível seus projetos baseados tanto no Spring como também nas tecnologias baseadas neste framework.

Os guias são muito diretos: fáceis de ler e sem rodeios. Precisa implementar um servidor REST? Quer usar o GORM? Quer começar algo? É enorme a possibilidade de haver um guia pronto para que você possa por a mão na massa rápido. Vale muito à pena conferir os guias: http://spring.io/guides. Além disto em cada subprojeto há um guia que te mostra o básico da tecnologia em questão.

Rejuvenescendo o Spring

Classes, métodos e pacotes marcados como obsoletos

Conforme o tempo passa todo projeto começa a sofrer com seu código legado. O pessoal da Pivotal então tomou uma decisão corajosa: marcou como obsoletas diversas classes, métodos e pacotes que compunham o código fonte do Spring. Você pode ver a lista completa neste link. Se seu projeto usa classes internas do framework (o que é uma péssima prática em qualquer framework), então algumas classes vão ter de ser substituídas em sua aplicação (você foi avisado!).

Do 3.2 para o 4.0 seu projeto funcionará perfeitamente, mas a partir da versão 4.1 é bem provável que diversas destas classes não venham mais com o framework.  Em um primeiro momento soa desagradável esta remoção em massa, mas na prática é vital para garantir a longevidade do projeto. Menos código legado leva a um custo menor de manutenção e possibilita um foco maior na inclusão de recursos realmente importantes para o desenvolvimento de novos projetos e para atender necessidades que estão surgindo.

Olhando para a frente: suporte total ao Java 8, Java EE 6 e 7

O Spring 4.0 foi lançado antes do Java 8 e já vinha com suporte total à nova versão da linguagem. Um ponto importante é que agora a versão mínima do Java é a 6.0: natural dado que o Java 5 já tem 10 anos (saiu em 2004). Você já pode tirar proveito de recursos como lambdas, referências a métodos, suporte total à nova API de tempo (java.time).

Do lado Java EE é importante mencionar que agora a versão mínima da especificação será a seis. Muitas dependências de terceiros (3rd party dependences) também sofreram com isto. A partir da versão 4.0 do Spring  estas devem ter sido desenvolvidas a partir de 2010. Exemplos interessantes: Hibernate 3.6+, EhCache 2.1+ e Groovy 1.8+.

O objetivo disto tudo é claro: estas medidas nos deram mais uns vinte anos de Spring (no mínimo) pois o custo de manutenção de tecnologias legadas daqui pra frente foi significativamente reduzido.

Groovy cada vez mais presente

groovylogo

Este é um ponto que muito me alegra: Groovy está muito mais presente no Spring 4.0. Nós que programamos em Grails já usamos a linguagem para declarar nossos beans (nos raríssimos casos em que isto é necessário) desde a versão 0.x do framework. É uma DSL bastante prática mas que até então estava disponível apenas para desenvolvedores Grails.

Agora qualquer um pode usar esta DSL: você não precisa mais do Grails para declarar seus beans em Groovy. È possível fazer isto em projetos Java de forma bastante tranquila graças à inclusão da Groovy Bean Definition Language.

Aqui faço uma aposta: a Pivotal percebe o valor do Grails. Prevejo cada vez mais recursos do Grails aparecerem no core do Spring Framework. Na versão 4.1 já está inclusive previsto o suporte a templates Groovy no Spring MVC.

Mudanças no container de injeção de dependências e inversão de controle

Foram incluídos alguns novos recursos que considero bastante interessantes. O primeiro deles diz respeito à anotação @Lazy. Até a versão 3.2 do framework nós apenas a aplicávamos na definição de beans, fazendo com que estes só fossem iniciados quando necessários. Agora ela vai além: podemos aplicá-la também em pontos de injeção!

A outra mudança interessante é que agora podemos usar generics como qualificadores de nossos beans. Abaixo está um exemplo que copiei direto da documentação oficial para ilustrar o seu uso:


@Autowired
private Store<String>  storeString;

@Autowired
private Store<Integer> storeInteger;

Em algumas raras situações é bastante prático.

Spring MVC com suporte a WebSocket!

wslogo

Uma adição que justifica o upgrade. Agora o Spring oferece suporte nativo à tecnologia WebSocket e, claro: da maneira Spring, ou seja, é fácil de usar! Mais do que isto, eles também oferecem suporte a SockJS, que é uma tecnologia de fallback que permite simular websockets em navegadores mais antigos.

E o melhor deixei pro fim: Spring Boot

spring-boot-project-logo

O Spring Boot não é um componente do Spring, mas sim um projeto independente. A idéia é tornar a criação de projetos baseados em Spring muito mais ágil, fácil, desburocratizada, leve e foda. E eles conseguem.

O foco principal por trás da versão 4.0 é tornar o desenvolvimento com Spring ainda mais rápido. O Boot nos possibilita isto ao trazer para o framework o conceito de “convenção sobre configuração”. Na documentação oficial do projeto você verá diversas vezes  “opinionated view”, mas no fundo o que querem dizer é “convenção sobre configuração” (COC).

O que é COC: para a maior parte das suas tarefas, a configuração é essencialmente a mesma. Então por que obrigar o programador a se repetir? O Boot trás uma série de configurações pré-prontas para você: se precisar de algo mais customizado, basta sobrescrevê-las. Diversos requisitos não funcionais já vêm pré-configurados no Boot, e isto irá te poupar muito tempo.

Mais do que isto, o Spring Boot facilita o desenvolvimento de micro serviços (já escrevi sobre esta arquitetura aqui e aqui) e muda bastante a visão que temos sobre o desenvolvimento Java EE. Pra começar, o servidor é embarcado por default, então você executa sua aplicação com o comando java -jar (também é possível gerar um war se você quiser).

E o tempo que você leva para iniciar um projeto Spring Boot? Apenas o de copiar e colar os trechos de código Maven presentes no site do projeto no seu arquivo pom.xml. E sabem de outra coisa? Este será o único XML que você usará em seu projeto (e já era assim na versão 3.2). Um dos objetivos do boot é acabar com o mito de que gastamos muito tempo com arquivos XML no Spring.

Infelizmente este post é pequeno demais para que eu possa falar mais a respeito do Boot. MInha sugestão é que você passeie pelo site oficial do projeto primeiro.

(sem exagero: na minha opinião este projeto muda radicalmente nossa visão sobre desenvolvimento de aplicações corporativas na plataforma Java)

Concluindo

Apesar das mudanças, o Spring 4.0 ainda é usado exatamente como estamos acostumados na versão 3.x. Há novos recursos, como a DSL em Groovy para declarar beans, mas tirando isto, tudo o que lhes falei no livro ainda é válido e não precisa ser alterado (se leu o livro e encontrou pontos que precisam ser alterados, entre em contato comigo, ok?).

O que fica claro lendo a documentação e diversos posts na Internet é que a Pivotal conseguiu rejuvenescer o Spring: e muito! Quando escrevi o livro muita gente não via vantagem em usar o framework dados os avanços do Java EE 7. Hoje com certeza o Spring está de novo na vanguarda: mais leve, tão simples como antes e surgindo projetos cada vez mais interessantes como o Spring Boot, Spring Data, Spring XD e tantos outros.

Estas foram as novidades do Spring 4 que mais me chamaram a atenção. E sabem o que acho mais bonito? Exatamente pelo fato do projeto sempre ter ser baseado apenas nos conceitos de Inversão de Controle, Injeção de Dependências e AOP permitiram que este evoluísse sem que com isto seus usuários necessitassem reaprender o framework em sua nova versão.

O framework evoluiu, mas você que conhece os conceitos (e torço para que tenha lido meu livro :)) não ficou obsoleto com isto: apenas ganhou alguns novos brinquedos para aplicar em seus projetos. ;)

PS:

já está planejada a atualização do “Vire o Jogo com Spring”. Se você comprou pela Casa do Código, receberá atualizações automaticamente. Então dá pra comprar agora e garantir sua atualização em um futuro bem próximo. :)

Semana Groovy #8

Links da semana

Como cai no Groovy e mergulhei no Grails: descrevo o início da minha trajetória com Groovy e a origem do Grails Brasil – http://www.itexto.net/devkico/?p=1907

10 tecnologias que empolgam desenvolvedores. Groovy e Gradle no topo! –  http://zeroturnaround.com/rebellabs/10-kick-ass-technologies-modern-developers-love/

Introdução ao Spring XD (Extreme Data), que tem como base Spring e Grails – http://www.infoq.com/articles/introducing-spring-xd

Groovy Weekly #31 – http://glaforge.appspot.com/article/groovy-weekly-31

Apresentações

Usando Groovy para escrever aplicações Android! A famosa apresentação que foi mencionada na primeira edição da semana Groovy agora está disponível! – https://www.youtube.com/watch?v=AebkFsfcuDg

Teste funcionalmente seus projetos Grails com GEB –  https://www.youtube.com/watch?v=McFoNTKD8Q0

CRaSH the shell for the Java Virtual Machine – um projeto interessantíssimo para aqueles que desejam um melhor monitoramento de seus projetos é o CRaSH. Basicamente ele nos fornece um shell no estilo SSH que nos possibilita inspecionar remotamente o funcionamento dos nossos sistemas e ainda executar algumas tarefas. Esta apresentação é um verdadeiro chamado para que todos nós passemos a usar esta tecnologia. :) – https://www.youtube.com/watch?v=ZRQwZfP2uIc

Entrevista com Juergen Hoeller sobre Spring 4, Java 8 e Spring XD – Juergen Hoeller foi um dos fundadores do projeto Spring. Interessante ouvir se você se interessa pelo futuro destas tecnologias – http://www.infoq.com/interviews/Juergen-Hoeller-QConNY-2014-Interview

Lançamentos

Groovy 2.3.5 – Diversas correções de bugs. Uma novidade desta versão é que se preocuparam com compatibilidade com versões futuras, pois incluiram um artefato chamado groovy-backports-compat23 (leia o post no blog do Guillaume Laforge a respeito: http://glaforge.appspot.com/article/groovy-2-3-5-out-with-upward-compatibility ). Vale à pena ler o release notes aqui: https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10242&version=20491. Em seguida, faça o download em http://www.groovy-lang.org/download.html

Spring 4.1 RC – Uma novidade interessante é o fato de que agora o Spring MVC vai ter suporte nativo a templates Groovy!  – http://spring.io/blog/2014/07/21/spring-framework-4-1-release-candidate-available

Projeto da semana

GR8 CRM – O objetivo do projeto é fornecer funcionalidades de CRM (Customer Relationship Management) para aplicações Grails. Consiste em um amontoado de plugins. Estes irão trazer funcionalidades como gestão de contatos, gerência de tarefas e de projetos, notas, etc. Sem sombra de dúvidas é bastante interessante e vale à pena navegar pelos plugins: http://gr8crm.github.io/

Posts clássicos

Guia itexto: o container de injeção de dependências do Spring – Por baixo do Grails há o Spring Framework. É muito importante que o desenvolvedor entenda os conceitos por trás do Spring para tirar máximo proveito do Grails. Neste artigo (que acabou dando origem ao meu livro sobre o mesmo assunto) todos estes conceitos são explicados em detalhe – http://www.itexto.net/devkico/?p=859

GORM por trás dos panos. GORM é o framework de persistência do Grails. Já faz algum tempo que passou a ser uma API independente também. O melhor lugar para entender seu funcionamento por trás dos panos é o guia para desenvolvedores do framework,que pode ser acessado neste link: http://projects.spring.io/grails-data-mapping/manual/index.html

Assine nossa newsletter!

Quer receber esta newsletter por e-mail no momento em que for publicada? Basta se inscrever preenchendo este formulário!

Modularizando JavaScript com Spring MVC e Jawr

javascript-logoEste post inicia uma série na qual vou expor técnicas que visam aumentar a manutenibilidade de código Javascript. Convenhamos: é uma linguagem de programação legal, porém muitas vezes o hype que a envolve nos impede de ver seus aspectos negativos. Neste post tratarei de uma das cicatrizes da linguagem que é a dificuldade que enfrentamos na modularização do código.

O problema: modularizar JavaScript usando Spring MVC

Se você tem a sorte de trabalhar com Grails tem à sua disposição uma solução maravilhosa que é o plugin resources que nos permite definir “módulos Javascript”. Infelizmente do lado Spring da cerca não temos algo tão popular. O que é um módulo Javascript?

Uma unidade de código que funciona em conjunto.

Muitas vezes esta unidade não é apenas um arquivo, mas vários, e é neste ponto que o problema começa a se manifestar. Imagine um módulo composto por dois arquivos: biblioteca.jsbiblioteca2.js. Sua equipe pode ter achado interessante dividi-lo em dois arquivos para paralelizar o esforço e com isto evitar todos aqueles incômodos relacionados ao merge de arquivos. Nesta situação, toda vez que você precisa usar este módulo, irá inserir em suas páginas código similar ao exposto a seguir:


<script type="text/javascript" src="/resources/js/biblioteca.js"></script>
<script type="text/javascript" src="/resources/js/biblioteca2.js"></script>

Ou então você poderia ter algum script que unisse os dois arquivos. O problema é que seria necessário modificar o seu processo de build e também fornecer garantias de que o arquivo gerado fosse sempre o mais atualizado possível (não é uma solução tãão bacana assim).

Agora, voltemos ao nosso exemplo. Imagine que este nosso módulo dependa do jQuery. Neste caso teríamos sempre de escrever o seguinte código em nossas páginas:


<!-- jQuery sempre irá ser carregado primeiro -->
<script type="text/javascript" src="/resources/js/jQuery.js"></script>
<script type="text/javascript" src="/resources/js/biblioteca.js"></script>
</span><script type="text/javascript" src="/resources/js/biblioteca2.js"></script>

Ainda pior: imagine que a ordem de carregamento dos arquivos biblioteca.jsbiblioteca2.js seja importante. Agora sua equipe precisa ser informada a respeito. Se for uma aplicação de uma única página, não será lá um grande problema, mas imagine uma aplicação maior, com mais de um template, etc. A coisa começa a se complicar.

A imagem a seguir expõe bem a situação do nosso projeto. Temos uma biblioteca composta por dois arquivos que depende de uma terceira:

jawr_dependencias

Não seria bacana se houvesse uma ferramenta que nos permitisse resolver os problemas a seguir de uma forma simples?

  • Documentar as dependências entre os nossos arquivos Javascript de tal forma que seja fácil para a equipe entender a organização interna do projeto.
  • Garantir que os arquivos sejam sempre carregados na ordem correta.
  • De alguma maneira otimizar o modo como estes arquivos são enviados ao browser: compressão via gzip, talvez até mesmo um merge dos arquivos.

Jawr entra em cena

logoJawr

Jawr é uma ferramenta que tem como objetivo resolver os três problemas que expus acima e mais alguns. Neste post irei tratar de uma parte bem pequena deste projeto: aquela que lida com Javascript. A grosso modo Jawr é um servlet que iremos inserir em nosso projeto fictício. Este servlet organizará nossos módulos Javascript em bundles.

O que é um bundle? É um módulo, tal como expus acima. Mais do que isto, um bundle alguns atributos fundamentais do nosso módulo:

  • Que arquivos compõem o nosso módulo
  • Em que ordem estes arquivos devem ser carregados
  • Quais as dependências do nosso bundle, isto é, que código este precisa para funcionar?

Voltando ao nosso projeto percebe-se que há dois bundles: biblioteca e jQuery, que podemos representar gráficamente tal como na imagem a seguir:

Nossos bundles

Nossos bundles

Poderíamos pensar em um bundle único composto pelos nossos arquivos da biblioteca e o do jQuery. O problema é que sabemos que jQuery será usado por diversos outros pontos da nossa aplicação: sendo assim é interessante que modularizemos esta parte a fim de que seja reaproveitada em outras partes do projeto.

Incluindo Jawr em nosso projeto

Nosso projeto é baseado em Maven. Sendo assim, para incluirmos o Jawr basta adicionar a dependência no arquivo pom.xml tal como no exemplo a seguir:

<dependency>
    <groupId>net.jawr</groupId>
    <artifactId>jawr</artifactId>
    <version>3.3.3</version>
</dependency>

Como disse logo acima, Jawr é essencialmente um servlet. Sendo assim temos também de alterar o arquivo web.xml para que fique similar ao exposto a seguir:

<!-- Servlet para lidar com Javascript -->
<servlet>
   <servlet-name>JavascriptServlet</servlet-name>
   <servlet-class>net.jawr.web.servlet.JawrServlet</servlet-class>

		<!-- Aonde se encontra o arquivo de configuracao -->
   <init-param>
       <param-name>configLocation</param-name>
       <param-value>/jawrJavascript.properties</param-value>
   </init-param>
   <init-param>
       <param-name>mapping</param-name>
       <param-value>/bundle/js/</param-value>
   </init-param>
   <load-on-startup>1</load-on-startup>
</servlet>
<!-- O mapeamento de URL -->	
<servlet-mapping>
   <servlet-name>JavascriptServlet</servlet-name>
   <url-pattern>/bundle/js/*</url-pattern>
</servlet-mapping>

Preste muita atenção no mapeamento de URL. Na documentação oficial do Jawr este é configurado para que lide com todos os recursos que terminem com a extensão .js. O problema com esta abordagem é que muitas vezes não queremos que todos os nossos arquivos Javascript sejam carregados como bundles. Talvez você queira ir adotando aos poucos a ferramenta em seu projeto (esta é a principal razão que vejo). Em nosso caso, Jawr só irá lidar com aqueles recursos Javascript que se encontrem na url /bundle/js/*. Nota importante: repare no parametro de inicialização mapping. Se for usar uma configuração como esta, este obrigatóriamente deve estar definido.

Configurando os bundles

No mapeamento do servlet foi incluído um parâmetro chamado configLocation. Em nosso projeto baseado em Maven este arquivo se encontra em /src/main/resources/jawrJavascript.properties. É neste arquivo que iremos definir todos os nossos bundles. Abaixo está um exemplo deste arquivo:

# Altere aqui caso esteja no seu ambiente de desenvolvimento
jawr.debug.on=false

# Devemos enviar os bundles compactados?
jawr.gzip.on=true

# De quantos em quantos segundos o servlet deve verificar se as configuracoes foram
# alteradas. Extreammente util em tempo de desenvolvimento!
jawr.config.reload.interval=30

# Primeiro bundle de exemplo: jQuery
# O identificador do bundle sempre é o que aparece antes do ‘.id’
# neste caso, é jquery
jawr.js.bundle.jquery.id=/bundle/js/jQuery.js
jawr.js.bundle.jquery.mappings=/resources/js/jquery-2.1.0.min.js

# Incluindo uma dependencia
jawr.js.bundle.biblioteca.id=/bundle/js/biblioteca.js
jawr.js.bundle.biblioteca.mappings=/resources/js/biblioteca.js, /resources/js/biblioteca2.js
jawr.js.bundle.biblioteca.dependencies=jquery

Um bundle Javascript é definido no arquivo com o prefixo jawr.js.bundle.[identificador do bundle]. A primeira linha, que termina com .id define como será a URL que define o nosso bundle. O bundle jQuery, por exemplo, sempre será carregado quando a URL /bundle/js/jQuery.js for acionada, enquanto o bundle biblioteca, pela URL /bundle/js/biblioteca.js.

Voltemos nossa atenção para o bundle biblioteca. A segunda linha da sua definição (mappings), define quais os arquivos que o compõe e a ordem na qual devem ser carregados. A terceira linha define quais as suas dependências. Neste caso, apenas uma: o bundle jquery.

Tendo feito isto temos todos os bundles em nosso projeto prontos para serem usados. O próximo passo é trabalhar no arquivo JSP.

Alterando o arquivo JSP

O projeto Jawr vem com uma biblioteca de tags bastante útil. Abaixo podemos ver um exemplo de sua aplicação:

<%– A declaração da biblioteca de tags –%>
<%@ taglib uri="http://jawr.net/tags" prefix="jwr" %>

<%– Carregando o bundle biblioteca –%>
<jwr:script src="/bundle/js/biblioteca.js"/>

E o que ocorre quando carrego a página? Obtenho o resultado a seguir:

<script type="text/javascript" src="/itexto/bundle/js/gzip_N1063700552/bundle/js/jQuery.js" ></script>
<script type="text/javascript" src="/itexto/bundle/js/gzip_N745101183/bundle/js/biblioteca.js" ></script>

Primeiro será inserida a dependência do bundle biblioteca e, em seguida, o código fonte do bundle biblioteca. Repare nas URLs: o Jawr irá automáticamente cachear os recursos Javascript. E sabem o que é mais legal? Ele também envia o Javascript comprimido (se o modo de depuração estiver desativado (veja as notas no arquivo que expus acima)). E não é só o conteúdo Javascript comprimido. Os dois arquivos que compõem o módulo biblioteca também são mesclados em um só, diminuindo assim o número de requisições necessárias. Simples assim. :)

Concluindo

Nese post apresentei uma pequena parte do projeto Jawr. Há mais neste servlet, que também pode ser usado para gerenciar recursos CSS e imagens. É importante salienar que a documentação do projeto é excelente: bem escrita e fácil de ser consultada.

Claro que a questão da modularização não termina aqui. Esta é apenas uma das soluções possíveis. Recentemente topei com um ebook online (e gratuito) chamado Writing Modular JavaScript with AMD, CommonJS & ES Harmony que trata da questão de uma forma muito mais profunda. Entra aí também o modo como escrevemos JavaScript (que não tratei neste post) e alguns outros pontos sobre os quais pretendo escrever mais a respeito em um futuro próximo.

O código fonte deste post pode ser acessado no meu GitHub: https://github.com/loboweissmann/jawr-testes

Bibliografia Spring comentada

Vire o Jogo com Spring Framework

Abandonei o blog por alguns meses para me dedicar à produção do meu livro “Vire o jogo com Spring Framework” pela editora Casa do Código. Foi um processo muito enriquecedor pois me permitiu reler vários textos (e conhecer novos) que de uma forma ou outra acabaram entrando neste trabalho.

Este post é sobre esta bibliografia, que, espero, possa guiar todos aqueles que assim como eu queiram se aprofundar nos conceitos básicos por trás do Spring que são a inversão de controle, injeção de dependências, AOP, arquitetura de sistemas, qualidade de software e até mesmo sobre o próprio Spring :).

Textos teóricos

The Dependency Inversion Principle – Robert C. Martin – Já falei sobre este texto em alguns pontos deste blog. É um daqueles que mudam sua visão a respeito do processo de escrita de software: você entenderá o que é a inversão de controle e quais os fatores fundamentais que determinam a qualidade de um sistema.

The Open Closed Principle – Robert C. Martin – Outro texto clássico, aonde é descrito o princípio de design “open closed”, segundo o qual nossas classes devem ser abertas para extensão e fechadas para modificação. É o princípio básico por tŕas do Spring MVC. Leitura obrigatória para quem quer modelar melhor seus sistemas.

The Liskov Substitution Principle – Robert C. Martin – O princípio de substituição de Liskov nos ajuda a entender o poder por trás de interfaces bem definidas. Está diretamente relacionado às bases por trás da Injeção de Dependências.

Design Principles and Design Patterns – Robert C. Martin – Robert C. Martin – O autor define o que é arquitetura de software e, ainda mais importante, o que são dependências e como nós podemos categorizá-las e resolver problemas que emergem conforme nossos sistemas evoluem. É um resumão dos três textos que mencionei acima.

Inversion of Control Containers and the Dependency Injection Pattern – Martin Fowler – Texto clássico, em que pela primeira vez (ao menos até aonde minha pesquisa bibliográfica foi) é feita a distinção entre inversão de controle e injeção de dependências. Dica: injeção de dependências é uma variação da inversão de controle.

Design Patterns: Elements of Reusable Object-Oriented Software – Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides – É o clássico que todo programador que trabalhe com orientação a objetos deve ter em sua biblioteca. Trata-se do livro que trouxe o conceito de padrões de projeto para o mundo do desenvolvimento. Quando lidamos com Spring, estamos o tempo inteiro lidando com um ou outro padrão, como por exemplo Facade, MVC, Template Method e muitos outros. Conhecê-los torna a leitura de qualquer texto muito mais simpels. (Editora Addison-Wesley)

No Silver Bullet – Essence and Accidents of Software Engineering – Fred Brooks – Outro daqueles textos que mudam a vida do desenvolvedor. Os conceitos apresentados neste texto são a base para a compreensão do porquê da qualidade ruim de nossos projetos e também uma excelente fonte de argumentos contra gerentes fanfarrões.

The Mythical Man-Month – Fred Brooks – O livro clássico no qual posteriormente foi incluído o “No Silver Bullet”. É fundamental para aqueles que queiram entender as dificuldades básicas, aplicáveis ainda hoje na escrita de qualquer sistema. (Editora Addison-Wesley)

The Mesa Programming Environment – Richard E. Sweet – Publicado em 1985 no SIGPLAN Notices, tem valor histórico inestimável. É a primeira vez que se fala alguma coisa sobre inversão de controle e injeção de dependências. Fascinante.

Expert One-To-One J2EE Design and Development – Rod Johnson – Publicado em 2002, expõe os principais problemas com o EJB da época e já expõe as bases que formarão o Spring Framework. É uma leitura riquíssima para todos aqueles que queiram conhecer as motivações por trás do framework. E tem dicas de arqutietura e design que ainda são aplicáveis hoje. Livro massa! (Editora Wrox)

Expert One-To-One J2EE Development Without EJB – Rod Johnson – Publicado em 2004, podemos dizer que o Spring aparece oficialmente pela primeira vez neste livro. O autor apresenta aqui algumas alternativas ao EJB (adivinha qual a mais popular?) e, de novo, vemos algumas práticas de arquitetura fundamentais que nos fazem entender bem aquela história da “ferramenta certa pro problema certo”. Excelente leitura. Assim como o livro anterior, não o considero ultrapassado e, numa boa? São clássicos que valem muito à pena ter na sua biblioteca mesmo daqui a uns 20, 30 anos. (Editora Wrox)

The Composite View Pattern – Time de desenvolvimento do Apache Tiles – Ao tratar do Spring MVC, gasto algumas páginas falando a respeito do Tiles, que é baseado no padrão de visualização composto. Este é sem dúvidas o melhor texto que conheço sobre a descrição deste padrão.

JSR-299: The new Java standard for dependency injection and contextual lifecycle management – Gavin King, Pete Muir, Dan Allen, David Allen – A documentação do Weld, que é uma implementação de referência do CDI, em teoria concorrente do Spring foi o melhor texto que já li sobre a descrição dos contextos. Perguntas do tipo: “o que ganho com um contexto prototype ou singleton?” são respondidas neste texto.

Java Transaction Design Strategies – Mark Richards – Este livro publicado em 2006 pela InfoQ é o livro sobre transações em Java, e é de valor inestimável para qualquer desenvolvedor que queira ter um conhecimento mais sólido sobre o assunto.

Na prática

Spring Reference Documentation 3.1 – SpringSource – Em teoria deveríamos encontrar tudo na documentação de referência oficial do framework. Infelizmente isto não é verdade: diversos dos problemas práticos com os quais o desenvolvedor precisa lidar no seu dia a dia não são tratados aqui, o que torna o aprendizado do framework muito frustrante quando usado como única fonte. Mas de qualquer maneira, é sempre bom dar uma conferida em caso de dúvidas.

Introduction to the Spring Framework – Rod Johnson – Este texto publicado em 2005 no site The Server Side ainda hoje – apesar de estar desatualizado – ainda é uma excelente justificativa para a adoção do framework segundo as palavras do seu próprio criador.

Spring in Action – Craig Walls – É dos poucos livros que li todas as edições. A última – terceira – foi publicada em 2011 e é considerado um dos melhores livros sobre o assunto. No entanto observei que já está desatualizado em relação a 2012. Este trata da versão 3.0, eu trato da 3.1. Algumas classes foram consideradas deprecated de lá pra cá. Não gosto do modo como a AOP é descrita (pra que afogar o leitor em conceitos de cara se posso ir apresentando-os de forma mais suave?), e diversos problemas práticos que enfrentamos com o Spring MVC simplesmente não são tratados. Interessante: ele sequer explica direito o porquê dos contextos do container. Bom: é um texto introdutório, com certeza farão críticas similares ao livro que escrevi. :) (Editora Manning)

Injecao de Dependencias com Spring Framework 3 – Henrique Lobo Weissmann – Neste texto eu procuro explicar como funciona o container de inversão de controle/injeção de dependências do Spring e os princípios por trás destes. Foi o que deu origem ao livro.

Use a Cabeça – Ajax – Bret Mclaughlin – É o melhor livro que conheço sobre o assunto. (Editora Altabooks)

Ajax: A New Approach to Web Applications – Jesse James Garrett – Um texto de imenso valor histórico. É neste texto que pela primeira vez a técnica Ajax é descrita. Ainda hoje é uma das melhores descrições que conheço sobre o assunto.

Spring 2.5 Aspect-Oriented Programming – Create dynamic, feature rich, and robust enterprise applications using the Spring Framework – Massimiliano Dessi – Livro interessantíssimo só sobre aplicações de AOP com Spring. É bacana porque podemos ver diversos exemplos e, com isto, entender melhor o quê é a AOP e, principalmente, para quê serve. (Editora PACKT Publishing)

Spring Enterprise Recipes – A Problem-Solution Approach – Jan Machacek, Aleksa Vukotic, Anirvan Chakraborty, Jessica Ditt – É um livro no estilo “receita de bolo” só com problemas envolvendo o Spring. Muito interessante pra tirar aquela dúvida rápida que a documentação oficial não consegue atender. Foi publicado em 2009 pela Apress, então está um pouco desatualizado, mas ainda tem muita utilidade.

O Código fonte do Spring – Gastar horas entendendo como funcionam as vísceras do Spring é um exercício fantástico. Anos atrás acabei por implementar o meu próprio container assim, e repetir a experiência foi muito gratificante.

Concluindo

Estes foram os textos mais importantes que usei na escrita do livro. Como mencionei, foi um processo muito enriquecedor, e aconselho a qualquer um este tipo de pesquisa bibliográfica sempre que desejamos nos aprofundar em algum tema. Torço para que vocês gostem da “síntese” gerada após este trabalho.