Bem, já usei JPA em projetos WEB pelo padrão MVC e foi muito bom. Porém, essa praticidade existe também usando swing em um projeto desktop ou usar resultset’s e statement’s já basta?
Não, até por que, se você usou da forma correta, sabe que o JPA é parte da especificação JEE e que swing é parte da especificação JSE. Ou seja, você teria uma série de dependências a adicionar para fazer com que o jpa possa funcionar.
1 curtida
Vale a pena, trabalhei com ERPs que usavam hibernate e facilita na hora de codificar, se o projeto for grande.
1 curtida
Como assim puro? Hibernate é uma especificacãi JPA. Confesso que não uso EntityManager e o Criteria do JPA, mas as annotations são impressindíveis.
The Java Persistence API (JPA) is a Java standards–based solution for persistence. Persistence uses an object/relational mapping approach to bridge the gap between an object-oriented model and a relational database. The Java Persistence API can also be used in Java SE applications outside of the Java EE environment
Fonte: https://docs.oracle.com/javaee/7/tutorial/overview007.htm#BNACJ
JPA pode ser utilizado em Java SE sim, sem problema algum, contanto que você tenha um provider no classpath e configure-o no persistence.xml.
A única desvantagem é a falta de suporte para transações controladas pelo container, afinal não há container. Acho que deve existir alguma solução para isso já pronta. Tem também a questão da injeção e pool de recursos, mas não sei se isso é muito necessário numa aplicação desktop com 1 usuário ativo.
@Luis_Augusto_Santos Nunca utilizei hibernate puro, ele possui muitas vantagens em relação a implementação com JPA? Se puder, pode exemplificar alguma?
Usar a API pública do provider ao invés de utlizar através dos proxies do JPA tem algumas vantagens. Você pode utilizar anotações específicas com funcionalidades diferenciadas, pode configurar aspectos como o cache também de uma forma diferenciada, coisas desse gênero. Basicamente, você vai ter acesso a ajustes mais finos e funcionalidades a mais, que a especificação do JPA ainda não prevê.
A principal desvantagem (que eu não acredito que seja tão desvantagem assim se vc utilizar um projeto grande como o Hibernate, mas é só minha opinião) é o fato de que você fica altamente dependente daquele provider. Se o projeto for descontinuado, você vai no mínimo perder umas horas para migrar tudo para um provider novo, coisa que teoricamente não aconteceria quando utiliza-se as interfaces/annotations genéricas do JPA, onde bastaria trocar o provider no classpath e mudar 2 ou 3 propriedades no persistence.xml.
Primeiro, o fato do hibernate puro ser auto dependente é a maior vantagem. Você não fica amarrado a um application server e nem precisará baixar um monte de dependências que o JPA exige.
Segundo, como o @lvbarbosa disse, você pode utilizar recursos mais específicos, como anotações exclusivas do provider (o hibernate é um provider, mas existem outros, como o eclipselink que só implementa o jpa).
Outro ponto favorável do uso de hibernate é que existe uma vasta documentação e exemplos de praticamente tudo o que você imaginar na web.
Sem contar que a abordagem do hibernate, baseada em sessão é, ao meu ver, extremamente mais simples e direta que a de gerenciamento de entidades do JPA.
Isso sem falar na possibilidade de criar um arquivo de properties e não precisar do xml.
Mas não precisa do servidor para rodar o JPA, ele funciona no Java SE também. Não tem um monte de dependências, é só 1 .jar com as anotações e interfaces do JPA (que inclusive é mantido pela Oracle e muda só quando sai versão nova).
O EclipseLink também tem ajustes específicos e melhorias, do mesmo jeito que o Hibernate. Mais informações aqui: https://www.eclipse.org/eclipselink/documentation/2.5/jpa/extensions/annotations_ref.htm
Também tem pra JPA, nunca deixei de encontrar nada que precisasse. Inclusive existem livros e livros ensinando JPA (eu gostei bastante do Pro JPA 2).
Ué, mas o EntityManager que o Hibernate implementa não é só um pequeno embrulho ao redor da sessão dele? É praticamente a mesma coisa, só que com o EntityManager você tem a vantagem de não estar acoplado à implementação, e sim às interfaces da especificação (que teoricamente são mais estáveis em relação à mudanças).