Pular para o conteúdo principal

EJB 3: Uma evolução sob os conceitos do Hibernate e Spring

Definitivamente o modelo de componentização definido no Java EE 5 e 6 evoluiu e melhorou muito. Mas, sem dúvida muita dessa evolução se deve às pressões do Hibernate e Spring Framework. Estes dois últimos frameworks nasceram baseados no conceito de POJO, que nada mais é do que a concepção de um modelo de componentização baseado em classes Java sem as regras impostas pelo EJB (curioso, sem o EJB não existiria o Hibernate ou o Spring).

A morte dos Entity Beans

O Hibernate nasceu da idéia de promover um modelo de persistência mais simples que o proposto pelos EJBs do tipo Entity Beans definido na especificação EJB 2.x. Este foi o primeiro tipo de EJB a sofrer com a evasão de desenvolvedores com o surgimento deste framework e a conscientização sobre os problemas nos Entity Beans. A partir de um modelo baseado em JavaBeans e o uso do JDBC, o Hibernate usa a Reflection API para gerar os SQLs necessários para persistir o estado de beans em diversos banco de dados relacionais, além de definir o conceito de dialeto para resolver as diferenças de sintaxe do SQL usado entre as diferentes implementações de banco de dados. Ao resolver efetivamente a persistência dos objetos em banco de dados relacional, a morte dos entity beans estava decretada. Não foi atoa que no Java EE 5, numa tentativa de resgatar um padrão efetivo entre os desenvolvedores, surgiu o JPA usando os mesmos conceitos do Hibernate e promovendo uma API padrão com base em vários dos seus conceitos. A morte oficial dos entity beans no EJB!

Teria o mesmo fim os session beans?

Já o Spring Framework nasceu para combater os problemas resultantes das idéias usadas nas definições de outro tipo fundamental de componente do modelo proposto pelos EJBs: os Session Beans. Usando a mesma proposta do Hibernate, o Spring Framework adotou o JavaBean como modelo de componentização aliado aos serviços enterprise com o auxílio da programação orientada a aspectos (AOP). Assim, o Spring Framework decretou a morte dos EJBs do tipo Session Beans.

O EJB renasce das cinzas impulsionado pelos Pojos

O Java EE 5, apesar de manter compatibilidade com as versões anteriores, aplica os mesmos conceitos usados pelo Hibernate e Spring Framework (JavaBeans e injeção de dependências, por exemplo), numa tentativa de evitar o êxodo de desenvolvedores da padronização. Dando o braço a torcer, o EJB 3 aplica um modelo baseado em POJOs (que ironia!) até eliminar a obrigatoriedade das interfaces home, remota e local (favorecendo uma modelagem OO efetiva, uso de herança, polimorfismo, design patterns e interfaces de negócios). Contudo, o Java EE 5 trouxe uma novidade que impôs uma evolução nos frameworks que foram os seus carrascos: O uso de anotações para eliminar configurações em XML. Poderíamos dizer que o EJB 3 não é uma mera cópia dos conceitos usados no Hibernate e Spring, mas também traz uma inovação ao fazer copy/paste/modify. Curioso foi ver que o Hibernate e o Spring foram obrigados a evoluir.

Contudo, podemos notar que o EJB 3.0 deixou de fora muitas das melhorias já presentes no Hibernate/Spring. No JPA 1.0 podemos notar a falta do mecanismo de "Criteria" e no EJB a falta de uma modularização mais flexível além dos tradicionais JAR, WAR e EAR. Tanto que agora no EJB 3.1 e JPA 2.0, várias melhorias tentam eliminar as deficiências reclamadas pela comunidade que já não existiam em versões antigas do Hibernate e Spring Framework.

Com as melhorias do Java EE 6, porque usar o Spring?

Muitos se questionam hoje se deveriam usar o Hibernate e o Spring considerando as evoluções do EJB 3 e JPA estabelecidas pelo Java EE 5 e 6. Acredito que pela simplicidade e padronização proporcionados no Java EE deveríamos usar o EJB e JPA. Mas, considerando as limitações deveríamos levar em consideração o uso do Hibernate e do Spring Framework. Apesar de não serem frameworks padrões, e por isso mesmo, não estão limitados às imposições políticas de vários interesses, estes frameworks têm a liberdade de evoluir e experimentar idéias inviáveis até o momento no Java EE, além de propiciar a integração com outros frameworks que também não são padrões e são legados ainda em uso pela comunidade (por exemplo: Struts, iText, Quartz, etc). Muitos conhecem as vantagens de usar o Hibernate diretamente em detrimento das limitações do JPA. No Spring temos a modularização através de OSGi e o uso pleno do AOP como parte da modelagem dos componentes de negócios das aplicações enterprise.

Apesar das melhorias amplamente comentadas no Java EE 6 através do EJB 3.1 e JPA 2.0, ainda é evidente muitas das vantagens do uso direto do Hibernate e do Spring Framework.

Qual será o próximo passo evolutivo destes frameworks e plataformas? A convergência?

Enjoy it!
By Spock
Twitter: @drspockbr
http://blog.spock.com.br/
http://linkedin.spock.com.br/
http://www.springbrasil.com.br/
Outros posts: http://blog.globalcode.com.br/search/label/Spock

Comentários

Postagens mais visitadas deste blog

Saiba como programar para Arduino sem ter nenhum hardware disponível

O Arduino já é uma tecnologia muito difundida entre os amantes de tecnologia. É difícil encontrar um profissional da computação que não brincou um pouco com esta ferramenta de prototipagem ou, que gostaria de fazer isso. Porém, em alguns casos, o programador quer conhecer o arduino mas não dispõe de nenhum hardware, nem mesmo da placa. Como isso poderia ser resolvido? A primeira resposta seria aquela mais simples e direta: ir as compras. Isso pode ser feito em uma loja física ou pela internet. No meu caso, por exemplo, tive a felicidade de encontrar em um site (não me lembro qual) um kit arduino, com um conjunto de sensores e um DVD com 41 vídeo aulas. Mas digamos que o profissional não esteja passando por um bom momento financeiro, ou ainda, simplesmente não queira comprar o Arduino sem antes conhecê-lo um pouco melhor. Para a última situação também já existe uma resposta, e diga-se de passagem, uma excelente resposta. Trata-se do site 123D Circuits.io . Depois de criar seu u

Entendendo como funciona a programação de computadores: linguagens de programação, lógica, banco de dados

Nesse post, diferente dos últimos que foram mais enfáticos nas experiências com tecnologias, vou focar um pouco mais nos profissionais que estão começando, ou pretendem ingressar na área de desenvolvimento de software, falando sobre conceitos fundamentais relacionados a programação em geral . Mercado de trabalho para programação Conforme já sabemos, o mercado de desenvolvimento de software, especialmente no Brasil, continua em franca expansão, sendo que cada vez mais as empresas buscam desenvolver seus próprios sistemas usando as mais diferentes e novas tecnologias. Algumas matérias interessantes: As seis profissões mais valorizadas em 2010 no IDG Now! Muitas vagas e sensação de reaquecimento da economia Por isso, a área de desenvolvimento de software tem despertado interesse em muitos profissionais de outras áreas que desejam mudar de profissão, já que as oportunidades de trabalho tendem a ser maiores. Esse é um perfil presente em muitos dos clientes da Globalcode que acabou m

JSON fácil em Java com GSon !

Ola pessoal ! O formato JSON ( J ava S cript O bject N otation) vem se consagrando cada vez mais na comunicação de dados, principalmente nos dispositivos móveis devido a esse formato ser mais leve que o XML e também mais legível. Uma prova disso são as inúmeras bibliotecas que existem para manipular esse formato, e no caso do Android, o suporte ao JSON é nativo. Mas apesar de ter esse suporte nativo, algumas operações devem ser feitas manualmente e o código acaba ficando um pouco verboso e repetitivo, já que para cada objeto que se deseja transmitir é necessário fazer um método que lê as propriedades do JSON e faz as devidas atribuições no seu objeto Java. Vamos supor o seguinte objeto sendo transmitido em JSON: {   user: {     id: 123456,     name: "Neto Marin",     username: "netomarin",     email: "netomarin@globalcode.com.br"   } } Se você fosse tratar um Webservice que envia esse JSON para o seu aplicativo Android, além de criar a o