Fragmental

8/31/2005

Spring em Ação

Não, não é lançamento de livro em português, não ainda (agradeçam, esse livro não é legal e não vale a grana).

Está acontecendo mais uma vez. Assim como com o Struts, o Spring está ganhando a luz do dia nas empresas após ganhar força na comunidade (e, assim como o Struts, em algum tempo perceberemos que podemos fazer bem melhor...).

Para quem (ainda) não sabe, o Spring é um container leve (container leve é um conceito vasto, mas neste caso quer dizer um container de POJOs, segundo o time do Spring). Com ele você pode ter praticamente todos os benefícios de Java Enterprise Edition (JCA, JTA, Servlets, Pools, JMS, TMX, JavaMail, JDBC...) sem utilizar EJBs. Você não precisava de EJBs para usar estas coisas, mas geralmente as pessoas se apegavam a estes por serem a maneira "mais fácil" de lidar com os outros recursos.

O Spring provê uma API fácil e bem utilizável para utilizar estes recursos, mantendo seus objetos independente destes com um bom uso de AOP (que é facilmente configurável por qualquer um).

O problema atual do Spring é como é chato configurar seu XML. A semântica do negócio é simples, mas é muito ruim ter que digitar aquilo tudo (não me apontem uma ferramenta, não é isso que torna as cosias produtivas), mas ainda assim é *muito* mais simples que configurar EJBs e seus descritores, interfaces, pools, JNDI names e tudo mais, fora as gambiarras como Service Locators e Business Delegates.

Existe um velho refrão que diz algo como Não use um canhão para matar uma mosca. Esta frase mais que sábia diz muito sobre quando usar EJBs (praticamente nunca), mas também tem suas complicações.

Um caso típico é o de programas em ASP clássico/PHP/CGI. Estas plataformas são extremamente limitadas para aplicações de grande porte, praticamente qualquer integração com middleware é feita por banco de dados (bleargh) ou hoje em dia por XML sobre HTTP. Eu trabalhei muito tempo com ASP, e quando estava estudando minha diversão era fazer cosias improváveis, como editores de texto completos, editores de vídeo e outras coisinhas complexas em ASP puro (não adianta usar componentes, muitas vezes você não consegue instalá-los no servidor do cliente).

E ficava aquela gambiarrada toda. Trocas de mensagens através de tabelas no SGBD, arquivos temporários de download... etc. Esse é o caso contrário do ditado que acabei de falar, neste caso podemos aplicar o refrão: Não use um mata-moscas para matar um mamute.

Existem aplicações que não são mamutes, não são moscas, mas ainda assim precisam de algum suporte de plataformas coorporativas, como transacionamento XA, pools, conectores, ciclo de vida controlados, mensageria... a maioria das aplicações que são mais que um simples site de Internet tem pelo menos uma dessas necessidades. Neste cenário, coisas como o Spring são perfeitas, você usa apenas o que precisa, não precisa engolir o elefante de novo para usar o que quer.

Neste cenário, fica mais fácil produzir aplicações Orientadas a Objetos de verdade, sem as aberrações de BusinessDelegates/SessionFaçade/ServiceLocator/DTO/TO/VO que vieram trazer alguma usabilidade aos EJBs. Mas se você é amigo dos EJBs, ou realmente tem um caso onde els são úteis (chamadas RMI são um dos raros exemplos), pode continuar utilizando sua plataforma.

Se você está no mercado, estude Spring. Provavelmente quando a sua empresa for enfim usar haverá coisa melhor, mas por enquanto, essa é a opção mais sensata para aplicações médias. Não que paltaformas como Pico/Nano Container sejam ruins, pelo contrário, só que o Spring tem maior suporte e um apaltaforma mais vasta, cobrindo muita coisa que você precisa hoje.

A fila anda...


 
f