Meu spike solution no Google Code

Gosto muito de desenvolvimento de software, e sempre que tenho um problema para resolver, ou uma ferramenta para testar, procuro fazer um projeto específico para isso, também conhecido, pelo pessoal de XP, como spike solution.

Uns anos atrás, fiz um freelance que não deu certo, no sentido de “ser pago” da coisa. Mas o código deste freela, foi usado em uma apresentação de JUnit que fiz no trabalho.

Desde então, sempre que preciso apresentar alguma ferramenta, que eu uso, pego este projeto para avaliar o problema ou testar a nova ferramenta, além de apresentar a solução.

Depois de um ano usando este projeto para avaliar ferramentas de desenvolvimento em Java, resolvi disponibilizar o código no Google Code para os que se interessarem sobre as ferramentos que uso.

Este é minha segunda publicação de código, espero que seja útil para mais alguém.

[],
AC

Outras razões para não usar o Spring

A questão que eu deixei no fim do texto sobre o porque eu não uso o Spring teve uma resposta.

O Felipe Cruz comentou duas funcionalidades que são interessantes. A primeira, que ele citou, é uma integração com outro framework então não conta :-)

Segue as funcionalidades e minhas considerações:

1. “É um container leve, que oferece infra para projetos Enterprise sem que seja necessário um container JEE”
   • No meu caso, as interfaces são web, ou seja, só o Spring não resolve, continuo precisando de um Container Web. E como o Container Web já possui essas funcionalidades, não seria uma “pleonasmo” usar o Spring? E container leve, por container leve, eu fico com o Jetty que é rápido pra inferno e beeem pequeno. =D
2. “O controle de transações é bem flexivel e em casos não triviais é mais fácil configurar declarativamente do que programáticamente”
   • Com a implementação que eu citei da DAOFactory, o controle de transação fica assim:

———————————————————–
factory.txBegin();

dao1 = factory.getDao(Entidade1DAO.class);
dao1.foo1(bla1);

dao2 = factory.getDao(Entidade2DAO.class);
dao2.foo2(bla1);

factory.txCommit();
———————————————————–

O código acima está no método do POJO. Os métodos txBegin() e txCommit() são os responsáveis por demarcar a transação. Tudo o que acontece dentro destes métodos acontecerá na mesma transação.

Mas esta mesma transação poderia ser controlada pelo Spring assim:

A imagem acima pode ser encontrada no site do Spring. Na parte que explica como funcionam as transações. Ou seja, a transação declarada é feita usando o container AOP para criar uma transação antes do método ser executado.

Quanto ao valor do Spring, penso ser indiscutível. Sem ele EJB ainda seria um porre para usar. Mas graças as propostas que o Spring e o Hibernate trouxeram, a especificação do EJB 3 o melhorou muito a plataforma de componentes distribuidos.

Mas o que eu tenho observado é que as funcionalidades mais interessantes do Spring só são atrativas quando a aplicação não irá executar em um container. Caso contrário elas se tornam duplicadas em relação ao container da aplicação.

Porque eu não uso Spring

O Urubatan está fazendo uma pesquisa sobre o uso do Spring.

Minha resposta foi simples: Não, por causa do XML.

Mas, na verdade não é só o XML do Spring que faz com que eu não me interesse por ele. Mas a falta de funcionalidades úteis suficiente para mim.

Se eu contextualizar minha situação, talvez, fique mais fácil me enteder… Eu desenvolvo sistemas de informação com interface web. Atualmente estou usando os seguintes frameworks em minha aplicações:

• Stripes: que é framework mvc para aplicaçõe web. É baseado em anotações e oferece, além de um ótimo front-controller, as funcionalidade de: convensão ao invés de configuração, templates para os JSPs através de taglibs, validação usando anotações e i18n;
• JPA com o Hibernate como provedor de persistência: Mapeamento Objeto-relacional.
• Estou usando também a DAOFactory dinâmica que eu apresentei em um outro texto.

As respostas afirmativas, da pesquisa, tratam de 5(cinco) motivos para justificar o uso do Spring, e aqui eu vou justificar o porque eu não uso o para resolver essas funcionalidades:

1. Container IoC: Das três APIs que eu uso, a única onde a fábrica, ou container IoC se você preferir, do Spring iria me ajudar seria com a fábrica de DAOs. Mas, neste caso, o preço do Spring, isto é, a configuração dele não compensa.
2. O gerenciamento de transações: como mostrado no texto sobre a DAOFactory dinâmica, eu faço a entidade de negócio controlar o início e fim das transações. E, ainda não vi a vantagem de colocar esse código em um XML. Se a necessidade de transações mudar será por conseqüencia de uma alteração na classe de negócio.
3. O framework MVC: Como disse anteriormente, utilizo o Stripes como framework mvc. E ele não tem um XML para configurar. Na verdade o Stripes permite que eu resolva um cadastro com uma classe e um JSP sem que a coisa toda pareça uma mesa de natal em familia portuguesa =D
4. O container AOP: Esta é a funcionalidade do Spring que mais me chama a atenção. Li um texto no site da IBM, no DevelopersWorks, falando sobre o uso de um DAO genérico utilizando o container AOP do Spring para recuperar as NamedQueries do Hibernate. Foi o principal motivo para eu me interessar pelo Spring. Mas, mais uma vez, o XML necessário para essa “mágica” se mostrou improdutivo quando comparado com a quantidade de código necessário para fazer a mesma coisa quando se recebe uma Hibernate Session no contrutor da implementação da interface DAO.
5. Integração entre os frameworks: Como eu procuro manter as camadas da aplicação bem definidas não estou tendo nenhum problema de integração. No máximo colocar um NamedQuery a mais com o fetch que estava faltando, para evitar os LazyLoadException do Hibernate.

O Spring é uma idéia muito boa. Ajudou muito na melhoria de padrões da especificação Java como o EJB3. Mas para quem reclamava da complexidade da arquitetura de componentes J2EE ele não foi muito feliz ao transportar código Java para código XML. Não que este seja complexo, mas é muito extenso o que o torna cansativo.

Ainda não estou convencido de que código xml seja mais produtivo do que código Java.

Reafirmo que, por hora, respondo ao Urubatan que não uso o Spring por causa do seu XML, desnecessariamente, grande. Mas que, na verdade, eu não uso o Spring porque encontrei alternativas mais produtivas. E que ele não fornece nenhuma funcionalidade indispensável para o desenvolvimento dos sistemas de informação em que eu tenho trabalhado nos últimos 4 anos.

Alguém teria uma situação em que o Spring seria mais produtivo? Um caso em que a factory dele seja muito útil ou mesmo indispensável?