I have been following this tutorial on the Springsource website in order to have basic knowledge of Spring. Everything went good.
Now, I would like to integrate Hibernate to this little application I wrote following this tutorial. I found documentation on different websites (including hibernate's website) but I still have a few questions before starting.
I read some stuff about JPA and I can use it as an abstraction layer on top of hibernate but I don't really understand what for.
In addition, I read somewhere that there is two ways to use hibernate, the first one is annotations and the second one is using javax.persistance, I am right?
Is there some recent documentation about how to use hibernate in an existing spring web application, as well as the different ways to implement it?
JPA is a specification, hibernate can be considered as a implementation of the JPA spec.
You can use either annotation for mapping file with hibernate.
The following tutorials are better:
Hibernate Tutorial Vaannila
Hibernate Tutorial Mkyong
JPA is a standard, Hibernate is an implementation, but has other/additional functionality.
The Spring Reference manual's section on ORM integration covers Hibernate. There are also scores of tutorials and demos, like here, but there are a bunch of other ones, and more recent ones.
Related
I'm writing a JavaFX Application which previously use Spring/QueryDSL for DI and persistence.
I'm hoping to move to using either Dagger or Guice (instead of spring) and Hibernate ORM.
I have noticed that Spring offers some nice functionality on top of hibernate, such as transaction management via #Transactional.
Are there other means of avoiding "boilerplate code" such as opening sessions, beginning transactions, committing transactions and closing sessions via some sort of hibernate configuration? Or are these features I'm really only going to get if I use Spring?
Guice has #Transactional support for JPA providers such as Hibernate using guice-persist, Dagger does not mention support for this.
If you are using Hibernate as your JPA provider, using Spring with #Transactional would probably be the most natural fit for building your backend. You would find a loss less documentation, examples, blog posts, books and online help in general using other alternatives than with Spring/Hibernate.
I'm wanting using JPA in ear project. Development project must be started ASAP so I have not a lot of time to research and investigate. Could you say please JPA API is restricted functionality of Hibernate or no. At this moment I'm using Hibernate directly. For example in future I'm planing to use hibernate-search and maybe hibernare-validate and -shard. Can I be sure that in future I will not have problem with using this.
And one more example - can I use HAR archive and JPA together.
Why JPA? For project will available RESTful service (jersey or resteassy implementation). And as I looked in much case using JPA for this. I'm a newbie in this so it's only my IMHO. May be i mistakes.
Thanks a lot.
Best regards
Artem
JPA is a subset of hibernate, but you're not limited to it. If you need a hibernate specific feature, you can generally use it at the cost of being tied to hibernate. For example, we've mixed in hibernate annotations with JPA ones, including the validater ones, without trouble.
JPA in theory lets you change the persistance provider later.
Sticking to only JPA compatible configuration can cause more trouble that is solved by the dubious promise of seamlessly swapping providers however.
I'm currently rebuilding an existing PHP application using Java. I therefore have an existing frontend GUI and an existing database schema that I'm working with.
Here is the technology stack I'm working towards:
jQuery, client-side
Wicket, front-end
Spring, ???
Hibernate, ORM
MySQL, database
Before reading about Spring in both Wicket In Action and the Hibernate documentation, I envisioned wiring the two together through my own business logic. I have experience with JBoss Seam, but am told that Spring is hardly comparable (although the documentation suggests otherwise, IMO). Short of adding a book about Spring to my reading list (I haven't found an appropriate one with good reviews yet), I'm at a loss.
What benefit(s) will Spring provide in this technology stack?
Subjective & optional follow up question: what reference material (book, website, etc) will get me started with the portion of Spring 3 I may utilize?
First, you can make your web application without Spring. But Spring will greatly facilitate things. Spring framework is a lightweight, non-invasive. Spring is like a kind of conductor. Among other things Spring helps you in:
To keep your objects loosely coupled. This will make your application more flexible and open to future changes
Powerful support for transactions through the AOP (Aspect Oriented Programming).
Object-relational mapping (ORM) integration module. Spring doesn’t attempt to implement its own ORM solution, but does provide hooks into several popular ORM frameworks, including Hibernate, Java Persistence API, Java Data Objects, and iBATIS SQL Maps. Spring’s Transaction management supports each of these ORM frameworks as well as JDBC.
The Spring MVC framework. Even though Spring integrates with several popular MVC frameworks, it also comes with its own very capable MVC framework that promotes Spring’s loosely coupled techniques in the web layer of an application.
A good book about Spring: Pro Spring
Spring, as noted in this review is non-invasive. It just wires your application components. And provides useful classes that make using other frameworks easier (JMS, JPA, etc). Spring doesn't force you to use its classes or interfaces anywhere.
What it handles is the creation of your components (objects), so that you can refer to a class' dependencies, without instantiating them. I.e. you say what your class needs, not how it is obtaining it. This makes the application very flexible.
That's in short - for more, read the linked article. It's not about the latest version, but that doesn't matter.
In addition to dependency injection, Spring offers features like declarative transaction management, simple integration with ORM, aspect-oriented programming support and many other nice things.
For documentation see Spring reference: http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html
#Dolph, in the simplest term, think of Spring as your application framework at the highest degree. This "framework" provides several "component buckets" where you can easily plug in different types of implementations. For example, for ORM, you may choose to use Hibernate over JPA or TopLink, for front end, you may choose Wicket over Struts or SpringMVC, and so forth.
The whole beauty of this (besides all the goodies stated in other posts) is it allows you easily swap out any of these implementations easily in the future. So, you can essentially rip out Hibernate one day and replace with TopLink, and it will never cause ripple effect to other components.
Another beauty of using Spring is your code becomes less clutter and has loose dependencies with other classes because you spend less time creating new objects yourself, Spring handles that for you. That said, you will quickly realize how easy for you to test your code because your API to be tested becomes very atomic. This is one primary reason why folks get discouraged in writing testcases, because they quickly realize that in order for them to test one API, they have to construct whole lot of things just to test that. Because of that, the whole process is brittle, imagine if you change that API, you need to reconstruct everything before testing it again.
Pro Spring book is good, mentioned by #JLBarros. I like Spring in Action very much. It is very very easy to read when I first got started with Spring. This is probably one reference book that I read from skin to skin.
This morning I was aboard a S-Bahn (German Subway) and I met a fellow student, who works for IBM. What he is doing there is Java EE optimization. I told him about my little project. And he recommended not to use 'oldschool' Hibernate. That's why my question is:
Is Hibernate deprecated?
(In combination with Java EE/Web Development)
..or did he just prate..
No, Hibernate is not deprecated.
However, there's now JPA (Java Persistence API), which is a standard API for doing the things that Hibernate does.
Note that JPA is just an interface specification. You'll need something that implements JPA, and Hibernate is one of the implementations of JPA. Besides Hibernate, there are a few others such as EclipseLink (the official reference implementation for JPA) and Apache OpenJPA.
Hibernate, apart from being an implementation of JPA, does provide a lot of extra advanced feature that JPA lacks of (extra syntax in query, QBC support etc). Some of them are really useful and hard to find a workaround in JPA world (yet). Without providing such features, it is hard to say JPA can "replace" Hibernate (hence, saying Hibernate being deprecating)
Hibernate is the JPA provider offered by JBoss, which is a Java EE server, so I doubt that Hibernate as an implementation is deprecated.
Perhaps he meant that using Hibernate within a Java EE server , bypassing the container-provider persistence, is deprecated and you should rely on our container for such services.
No, there is no way that Hibernate is deprecated. There is the JPA which is a persistence specification and Hibernate implements it. Also Hibernate has its own advanced features that JPA does not have and that's why Hibernate is the main source of new features that are added to the JPA standard.
One possible reason why he may have suggested you against Hibernate is that for a small project, the overhead of understanding Hibernate can be quite significant.
Hibernate is vast to say the least. Though it can be used in a simple way, but to find that out too, you'll need to comprehend a whole lot more.
but be rest assured that Hibernate is NOT deprecated, or going to be any time in the distant future. it's just that if your ORM needs are modest, you might want to try other solutions like iBATIS
JPA is only one way to do it. There's still Spring and all the other frameworks where Hibernate is well alive.
Based on what you said, it sounds like he may have been referring to Hibernate xml mappings, in contrast to using Hibernate annotations or JPA. XML is most certainly old-school rubbish.
I'm researching the development of Enterprise Applications in Java, .NET and Groovy. For each platform, we're going to try how hard it is to realize a simple SOAP web service. We'll use the tools and libraries that are most commonly used, to research the real world as accurately as possible.
In this regard, when using Hibernate for persistence, would it better reflect the real world to use the new JPA (Java Persistence API), or the Hibernate custom API that existed before JPA came around?
As you're probably already aware, as of 3.2 Hibernate is JPA certified. You can easily use Hibernate as your JPA provider without having to use any of Hibernate's "custom" APIs.
I'd recommend using straight JPA with Hibernate as the provider. And use annotations rather than XML (much nicer).
Then when you need a little something extra you can always get the Hibernate Session. For example I often find I need to do this in order to pass a collection to a query as a parameter (setParameterList).
It's funny how you worded your question
new JPA ... or plain old Hibernate
Sounds like one has been around forever and the other has just been released. Of course it's not true. JPA was influenced not just by Hibernate but also by TopLink and by J2EE entity beans. The first reference to JSR 220 draft is back from 2003 - how is that for new?
If you use JPA with Hibernate you still use Hibernate and is free to apply any proprietary extensions Hibernate has.
So the choice is yours: use proprietary API or use equivalent established and standard API...
You could stick with a pure JPA spec, just in case you want to swap out Hibernate, but what you'll probably find at some point is that you're never going to swap it out, and you've been missing out on all the really great Hibernate-specific features.
I'd recommend using Hibernate directly, and as Damo suggests, annotations instead of XML. Make sure you have a firm understanding of the "magic" that Hibernate brings. If you're not careful, you could really thrash the database. For example, there's an n+1 query problem depending on how you do #OneToOne joins:
Hibernate OneToOne automatic join fetching (resolving n+1 problem)
I'd also recommend to use an embedded database for unit/integration tests on your Hibernate queries, and watch the SQL that's generated to make sure it looks like something you'd write by hand.