I have gotten alot of feedback about architecture questions from both the Hibernate and Spring forums...I really appreciate it!!!

I just have another question. I have been researching Hibernate and am doing a Brown Bag on it for my team to show that it is the best persistence solution out there for our purposes. But I worked on Hibernate on another project and I know we had to write a few classes to control the creation of SessionFactories, classes for flushing and closing Sessions, and other Hibernate helper type classes. Then I began reading about Spring and quite a few people rave about the benefits it adds for integrating Hibernate into a system. Is it recommended when creating an architecture from scratch to utilize Hibernate with Spring....to use Spring for controlling things like the creation of SessionFactory and other Hibernate related features?

Thanks,

jay

I use spring, but not with hibernate - hibernate have good API and spring is only envelope for hibernate API

You can use spring, of course

regards

Spring wrappers were a good idea for Hibernate 2.x if you didn't want to write a few things yourself. With Hibernate3 you get:

- unchecked exceptions, no need to wrap

- typed exception hierarchy, not much practical use but nice in some situations

- auto flushing and auto closing of the Hibernate Session in JTA environments

- a lot more...

This is the only code you need to startup Hibernate, put it in any class you like (the static block is loaded once):



Now open Sessions from this factory whenever you need, if you run with EJB Session beans they will be flushed and closed automatically when your container transaction ends.

Another common thing people do is the "Open Session in View" with the "ThreadLocal Session" pattern. Download CaveatEmptor from http://caveatemptor.hibernate.org/ and have a look at the HibernateUtil class. It's about 50 lines of trivial code (open/close) around two ThreadLocal variables for the Session and Transaction that can be easily reduced to 25 if you don't need it verbose. Use some interceptor (e.g. from your web framework or from your EJB container) to handle the Session and Transaction in whatever scope you like.

If you use Spring and wire up your dao dependencies thru interfaces in the bean factory, it becomes trivial to switch dao implementations or to mix them.

I'm not sure if it's still there, but one of the best practices in the Hibernate reference was to abstract your hibernate code away from your domain objects. Spring makes this very simple.

By using the HibernateDaoSupport class as a subclass for your HibernateDao's, you can implement them very quickly. If you extract an interface, it's trivial to implement a JDBC version or JDO version of your dao.

None of your classes that need to use the dao will be aware that you are using a JdbcDao or a HibernateDao.

This becomes a selling point for hibernate: if you decide not to use it, reimplement your dao's with another strategy. If you have XP'ers on your brown-bag session, you can relate it in terms of reducing the cost of change by eliminating dependencies.

MyServiceObject -> MyDao
myDao <= MyHibernateDao
myDao <= MyJdoDao
myDao <= MyJdbcDao

Just implement your dao, update the spring config file, and restart your app.

An added benefit is that it makes testing easy using an alt spring config file:
MyServiceObject->MyDao
myDao <= MyMockDao

So, while hibernate 3 makes using hibernate easier like using hibernate through Spring, Spring still has the added benefit of making it easier to swap out hibernate for something else if necessary (and of course, it won't be!).

I think that saying 'always' might be a little drastic.