Breve Histórico
Quando EntityBeans não existiam (EJB 1.0), todos sabiam usar o famoso pattern DAO, mas isso ainda não era produtivo.
Quando surgiram os Entities BMP(Bean-Managed Persistence) no EJB 1.1 e o CMP(Container Managed Persistence) ainda era uma promessa, pois poucas implementações eram de fato funcionais, os sistemas ainda apresentavam um bom uso, ainda que houvessem alguns erros de design nos frameworks, o caos ainda não estava totalmente presente.
Na spec 2.0, o CMP, o grande vilão da spec 1.1, foi super melhorado, e se você não abusasse de Utopia nos relacionamentos e herança de EntityBeans, você teria um sistema estável. Eu digo isto, pois de fato sempre ouvi muitas reclamações destes modelo, mas além de um XML(descriptor) super complexo para representar os relacionamentos, algumas coisas simplesmente não eram pra ser feitas da forma mais bela e romantica, como relacionamentos n-n , ou 1-n com n-1 em 1-n numa cascata, o resultado dessas práticas quase sempre eram operações lentas, o que acabava fazendo com que o modelo CMP fosse abandonado.
Durante a fase do EJB 2.0 e 2.1 usei bastante CMP 2.x, principalmente no JBoss, que a partir de uma versão que não me recordo agora, usava Hibernate por debaixo dos panos como implementação de CMP.
Consequências de Problemas com EJB
Surgiram vários frameworks para resolver o problema do EJB, assim como várias confusões do mercado; uma das maiores foi e ainda é para algumas pessoas: Quem usa Spring não precisa usar EJB ou vice-versa.
Spring têm conceitos fantásticos, como IoC, Aspectos, Templates para DAOs e etc, mas quando falamos em sistemas de grandes número de transações, alta disponibilidade, clusterização, alguns componentes com essas necessidades é aconselhável que sejam ainda EJBs, note que não me referi a persistência. E o spring entra como uma simples “capa” para acesso a estes componentes mais robustos de uma forma abstrata e fácil.
Outro elemento que ganou notoriedade foi o Hibernate, resolvendo de forma mais simples vários cenários que o CMP deixava a desejar. Logo chegávamos a conclusão que poderiamos ter camadas de serviços transacionais (Spring ou EJB), acessando o Hibernate como mecanismo de persistência.
Ainda restava um “problema”, muitos XML’s, e muitas camadas, sendo assim o EJB 3.0, com o advento das Annotations, tentará resolver de forma simples nossos problemas, oferecendo facilidade e transparência no desenvolvimento.
JPA: Novos EntityBeans
Java Persistence API, é de fato uma forma simples e objetiva de desenvolver aplicações com acesso a banco de Dados. Imagine quanto tempo você perdia para migrar uma aplicação de Hibernate 2.0 para 3.x, ou pior de Hibernate para TopLink? Mudar XML’s, mudar queries e varias outras coisas…. Bom, JPA resolve isso de forma realmente simples.
Sem XML, mas com Anotações (e nem tantas)
De alguma forma você precisa informar o que e como vai ser persistido alguma informação, sendo assim para um bean que represente um Treinamento teriamos:
@Entity(name=”treinamentos”)
public class Treinamento implements java.io.Serializable {
@Id
private String codigoTreinamento;
private String nome;
private String cargaHoraria;
private String conteudo;
private Double valor;
private String textoVendas;
Note, que há apenas 2 anotações, uma para descrever que esse Bean é um Entity, e outra para identificar a Chave-Primária. Ai você pergunta: Cadê o XML? De fato você não precisa especificar 1 XML para cada POJO que você queira persistir. Mas há sim, um XML que chama-se persistence.xml
Sobre o Persistence.XML
Esse é um dos XMLs que ainda resistem em exisitir, o PersistenceProvider, que é o fornecedor da implementação , sendo assim você pode usar TopLink ou Hibernate, trocando apenas JARs e um pequeno detalhe dentro do XML.
Observe que você também pode usar DataSources também, e na seção class do provider, é onde vão suas classes com as anotações e sem mais se preocupar com XML’s
O arquivo persistence.xml deve ficar na pasta META-INF do seu jar ou um jar visível da aplicação, automaticamente ele será carregado e ai você vai poder usar isto tanto numa aplicação Web quanto Desktop.
Salvando os Dados
Para salvar os dados você vai precisar de uma Factory e um EntityManager, isto é construído a partir do Provedor da implementação com a ajuda do arquivo persistence.xml. Em tese isto é tão simples quanto obter a SessionFactory do Hibernate, mas no meu ponto de vista é bem mais fácil:
/**
* @author edgarsilva
*/
public class TreinamentoPersistence extends AbstractPersistenceBroker {
public TreinamentoPersistence(){
super();
}
public void store(Object obj) throws FrameworkException {
dataStore = factory.createEntityManager();
try{
dataStore.getTransaction().begin();
dataStore.persist(obj);
dataStore.getTransaction().commit();
} catch(Exception e) {
e.printStackTrace();
dataStore.getTransaction().rollback();
throw new FrameworkException(e.getMessage());
}
finally {
dataStore.close();
}
}
A classe AbstractPersistenceBroker não tem relação com OJB(ObjectRelationalBridge), e sim é parte de um projeto de framework novo que estou desenvolvendo(ela têm irmãs: AbstractRemotePersistenceBroker(EJB)). O código desta classe seria:
/**
* @author edgarsilva
*/
public abstract class AbstractPersistenceBroker {
protected static final String PERSISTENCE_UNIT = “btu”;
protected static final String LAYER = “PERSISTENCIA”;
protected static Logger log;
public static EntityManagerFactory factory = Persistence.createEntityManagerFactory(PERSISTENCE_UNIT);
protected EntityManager dataStore;
/** Creates a new instance of AbstractPersistenceBroker */
public AbstractPersistenceBroker() {
log = Logger.getLogger(this.getClass().getName());
}
public abstract void store(Object obj) throws FrameworkException;
public abstract void update(Object obj) throws FrameworkException;
public abstract void remove(Object id) throws FrameworkException;
public abstract Object load(Object id) throws FrameworkException;
public abstract Collection findAll(Object obj) throws FrameworkException;
EJB 3.0: fácil & simples
EJB 3, principalmente nos EntityBeans, ficou super simples, além dos SessionBeans, BMP e etc, claro que em paralelo o Spring 2.0 está trazendo grandes novidades, ainda mais com o poder do Spring-Annotations, que pode tornar fácil também seus projetos com este framework.
Independente do uso do Framework, é sempre bom pensar em criar mecanismos que facilitem o desenvolvimento, hoje em dia vivemos um momento de “porpurina” em vários frameworks, que os EGOS exarcebados promovem uma porção de complexidade desnecessária, ou seja, nomes e classes super bonitas, que ao invés de facilitar, acambam criando o desenvolvimento mais confuso.
E não esqueça, usar os padrões J2EE, facilitam portabilidade, ainda que seja mais chato o desenvolvimento, ao menos você não terá tanto trabalho em mudanças de ApplicationServers, Bancos e etc…
Bons códigos
Entries (RSS)