Spring and Hibernate

[paul wheaton]

I just got back from a mini conference that left me ... feeling .... weird.

There were a few gold nuggets, but there were two bits of technology that were pushed mighty hard. Iit's like several of these folks were singing from the same songbook.

The groovy stuff looks interesting. Very interesting. I'm excited about it.

I tried to learn about Spring, but I guess I must be thick. It looks like the goal is to replace four lines of java code with 20 lines of XML and say that it's simpler because there is now less java. It's touted as a lightweight replacement for EJB. But it doesn't have clustering unless you put it in an EJB container (that's what they told me). With so many people singing its praises, I just feel I must be really, really dumb to not get it.

Hibernate was the second song from the same songbook. O/R tool. I was burned by ObjectStore once. And I've been to O/R presentations and hibernate presentations and they all smell an awful lot like ObjectStore. And I find dead bodies behind lots of O/R tools. I just haven't found any dead bodies behind hibernate .... yet. Any O/R tool makes me squeemish.

Am I the only person feeling a bit nervous about these technologies?

[David Gospel]

..sigh... ...sigh.. ...sigh... ..

[Peter den Haan]

Originally posted by Paul Wheaton:
I tried to learn about Spring, but I guess I must be thick. It looks like the goal is to replace four lines of java code with 20 lines of XML and say that it's simpler because there is now less java.

It may not look like it in "hello world" examples, but I'm seeing 20 lines of Java code replaced by 4 lines of XML that are a lot less likely to be buggy. The code also becomes a lot easier to unit test because all collaborators are parameterized. Finally, I find that the dependency injection approach encourages the team to employ a more decoupled OO programming style that produces better maintainable code generally.

It's touted as a lightweight replacement for EJB. But it doesn't have clustering unless you put it in an EJB container

Spring is not "a replacement for EJB" as such. It's something that is a viable (and indeed preferable) alternative to EJBs for a large number of use cases. Spring does not aim to replace EJBs wholesale - they both have their place.

The problem with EJBs is that they have been conceived as a distributed technology, but most of the time you don't need distributing or clustering beyond some simple HTTP load balancing. In those cases, EJB forces you to deal with lots of added complexity for no particularly good reason at all. In those cases, Spring can provide the same set of services - declarative transaction management, pooling, (soon) security, resource lookups, and so on and so forth - in an a la carte fashion with a very simple POJO programming model.

If you do need clustering you have entered the kind of territory where EJBs shine. You might still choose to use Spring within the EJB tier for the other benefits it brings - dependency injection, custom aspects, more flexible transaction management - but you would rely on the EJB container for clustering and pooling.

And I find dead bodies behind lots of O/R tools. I just haven't found any dead bodies behind hibernate .... yet. Any O/R tool makes me squeemish.

Hibernate is a fabulous tool. But make no mistake, working with an O/R mapper is fundamentally different from working with JDBC (or a JDBC wrapper such as iBatis or Spring) and you will need to get up a sizeable learning curve once you start using it in anger.

Is it worth it? Sometimes it is, sometimes it isn't. Is your application sufficiently complex? How much behaviour is there in your data? Do you need an object model? How non-trivial is the relation between object model and database?

- Peter

[paul wheaton]

Since writing the first post, I've learned a little more about spring.

One approach to using it is that your client can be unaware of whether it is a POJO in the same VM or an EJB on another box. While this can be cool, it seems that you would want to have a business need for this feature.

AOP is another thing that has a very high cool factor and a very high heebie jeebie factor. I suppose AOP within a small library is okay. But for in-house use, it seems like it can easily add to maintenance and debug headaches. Some guy opens some code a year down the road and is trying to fix an old bug - the debugger (or stack trace) insists that there is a method being called in a class that just isn't in the source ....

Hibernate: one of the guys at the conference said an interesting thing. Something like relational stuff and object stuff just doesn't mix well. There will always be warts. And each O/R product is just going to move the warts to a different place.

Back to spring: I agree that EJB has been overkill for 90% of the EJB projects out there. And the complexity of it is a damn good reason to just not use it. It does seem that a lot of the failover/clustering features are better served by a good router. So you could then use servlets. The transaction stuff in EJB is pretty sweet and apparently spring provides something almost as good.

I dunno. I guess I felt that spring was being hyped pretty hard and it would have been nice to have a point by point comparison on spring vs. EJB vs. servlets.

I just wanted to feel around here and see if these things are as good as the hype and I should pay closer attention, or if these guys are neglecting to report the downsides.

[Don Stadler]

For what it's worth, at my company we did a project comparing Hibernate with a couple flavors of JDO, and Hibernate was the only one we really got to work decently. We used it for the first iteration of a project and I liked it. On the other hand JDBC would have been simpler for that iteration (and probably the next one).

I'm also looking at Spring, and thinking of subscribing to the SourceBeat book on it coming out soon.

[Peter den Haan]

Originally posted by Paul Wheaton:
One approach to using it is that your client can be unaware of whether it is a POJO in the same VM or an EJB on another box. While this can be cool, it seems that you would want to have a business need for this feature.

Well, you don't need Spring for that, and given that remote APIs should be radically different from local interfaces you would in practice expect at least a local business facade to adapt between local and remote APIs. So much for transparency.

AOP is another thing that has a very high cool factor and a very high heebie jeebie factor. I suppose AOP within a small library is okay. But for in-house use, it seems like it can easily add to maintenance and debug headaches. Some guy opens some code a year down the road and is trying to fix an old bug - the debugger (or stack trace) insists that there is a method being called in a class that just isn't in the source...

Spring AOP is about an evolutionary rather than revolutionary use of AOP. You aren't surprised or worried when container transaction management shows up in an EJB tier stack trace, even though it's not in the EJB source - why should you be any more surprised when Spring transaction aspects shows up in the stack trace?

We have been using aspects for years. Except that we didn't call them "aspects". We called them "container managed transactions" and "container security" and so on. They were fixed, inflexible and intrusive aspects, rather than lightweight and customisable ones. The flavour of AOP supported by Spring - some would argue it isn't "proper" AOP at all, whatever that may be - is just a single, logical step up from what we are already comfortable with. In that, it's quite different from, say, AspectJ's fine-grained, pervasive AOP which is undisputably revolutionary, and arguably something that the field of software engineering is just starting to get to grips with.

Hibernate: one of the guys at the conference said an interesting thing. Something like relational stuff and object stuff just doesn't mix well. There will always be warts. And each O/R product is just going to move the warts to a different place.

Absolutely true; physics students call it "the law of conservation of misery". The designer's trick is to move the warts to where they hurt least for the project at hand.

[...] It does seem that a lot of the failover/clustering features are better served by a good router. So you could then use servlets. The transaction stuff in EJB is pretty sweet and apparently spring provides something almost as good.

IMHO, Spring provides something better: you get a choice between using XML configuration or @annotations to declare transactional behaviour, and if you wish you can dictate exactly which exceptions roll the transaction back and which ones don't. And that's just the out of the box stuff; if you need some totally custom behaviour, you can implement your own transactional aspects.

I dunno. I guess I felt that spring was being hyped pretty hard and it would have been nice to have a point by point comparison on spring vs. EJB vs. servlets.

You might enjoy J2EE without EJB when it comes out. I'm prejudiced though - I reviewed a number of chapters.

I just wanted to feel around here and see if these things are as good as the hype and I should pay closer attention, or if these guys are neglecting to report the downsides.

IMHO, Spring is as good as the hype; the most significant disadvantage I found is the learning curve the team had to go through (but we went the whole hog at once: Spring container, AOP, Spring MVC framework, Hibernate...).

- Peter

[Chris Mathews]

Paul, to some extent I think you are missing the point about Spring. It is not about being the cool kid on the block, it is about producing high quality software that meets the practical needs of J2EE Developers. One of the goals of the Spring Developers is to write code that is so simple it is boring to read. This stands in high contrast to a lot of those whiz-bang kids churning out OSS just to show the world how smart they are. Spring was founded by Rod Johnson, who is a very experienced J2EE Developer, and born out of the difficulties that he met on actual J2EE projects. This isn't some fly by night product that is a solution looking for a problem... nearly every part of Spring has its roots in real life problems. Another important thing to remember when discussing Spring is that it has a very broad scope. It is very comprehensive with many distinct parts. The best thing is that Spring is not an all or nothing solution, you can use the individual parts piecemeal if you so desire.

Here is a quick overview of the various parts of Spring...

Spring-AOP
Spring includes a full AOP implementation (that uses Dynamic Proxies or CGLIB). Unfortunately, the mistake that most people make is in understanding the goals for Spring-AOP. It was not really intended for use on a fine-grain level compared other AOP Frameworks like AspectJ, AspectWerkz, Nanning, or DynAOP. The Spring developers are even quick to point out that if you want to do fine-grained AOP then you are probably better off using a solution like AspectJ. The Spring-AOP solution is really intended to be used to provide enterprise services such as resource pooling and transactioning. In fact, if you are just interested in these services then you don't have to directly use the Spring-AOP code at all. In general, I would say the average Spring using won't directly touch AOP.

Spring-IoC
This is where a lot of the magic that is Spring takes place. Like PicoContainer, Spring supports both Constructor Dependency Injection and Setter Dependency Injection. One of the most complex parts of writing any application is managing dependencies. We go to great lengths to create layer upon layer of indirection in an attempt to keep our code as decoupled as possible. Of course, the benefits to decoupled code speak for themselves and Spring-IoC makes this task almost painless. In fact, most of Spring's power and flexibility comes as a direct result from its IoC implementation.

Spring-Transaction Management
This is one of those areas of Spring that really shines. One of the primarily motivations of using EJB, as I mention here, is and has always been declarative transaction management. In particular, the use of JTA to manage global transactions across multiple transactional resources. Spring allows the use of declarative transaction management without an EJB Container for both local and global transactions. It doesn't matter if you are using plain JDBC, JTA, Hibernate, or JDO your transaction management stays the same.

Spring-DAO
If you are still doing straight JDBC (which I know you are with Jenny) then you need to look into this package. Spring-DAO greater simplifies writing JDBC code, all of the mundane setup work that goes into writing JDBC code is abstracted away. All the resource handling is done automatically for the developer so there is no chance of forgetting to close a Connection, Statement, or ResultSet anymore. Spring-DAO handles all of the basic flow like statement creation and execution and leaves the developer to extract the results. Spring-DAO even provides a nice consistent set of Exceptions for all data access.

Spring-ORM
Spring provides a nice abstraction layer on top of Hibernate, JDO, and iBATIS. Spring ORM managing many of the low-level details such as Session management in Hibernate and PersistenceManager management in JDO. Add in the nice consistent Spring-DAO Exception Hierarchy and Spring's declarative transactioning and you get a really powerful alternative to CMP.

Spring-EJB
Just so you don't get the wrong impression, Spring also supports EJB in the form of convenient superclasses and a transparent access API. When using Spring-EJB your client doesn't need to have any knowledge of EJB or perform any JNDI lookups.

Spring-Other
In addition of the above, Spring also has numerous other miscellaneous features. These include APIs for JNDI, Job Scheduling (using Quartz), Remoting (using RMI, JAX-RPC, Hessian, or Burlap), JavaMail, even a full MVC Framework, and more. Like I said, Spring is very comprehensive, there is something for everyone.

I think the comments about clustering are a bit off the mark. A Spring application can certainly be clustered without the use of an EJB Container. We would just be clustering at the web application tier. Overall, Spring is an enormously powerful framework that is certainly worth the hype that it is receiving. There is a bit of a learning curve but once that hurdle is jumped it becomes a joy to behold.

[Peter den Haan]

Originally posted by Chris Mathews:
I think the comments about clustering are a bit off the mark. A Spring application can certainly be clustered without the use of an EJB Container. We would just be clustering at the web application tier. [...]

You're absolutely correct. I was thinking of independent scaling of web and business tiers - and therefore, remoting between them.

- Peter

[Andres Camacho]

Hi all,
Lets say I'm working on a small greenfield project and I'm definitely going with Hibernate (because I've used it before). I think I like what Spring is all about and I'm willing to give it a try. Lets say I'm interested in alternatives to Struts so I want to adopt both Spring's persistence layer and its MVC layer.

The thing that is not clear to me yet is the relationship between the DAO objects and the MVC form objects in Spring. Are they separate? Can they be the same? Does anyone know of a good example that showcases not only the Hibernate side of Spring but also the MVC working together?

I'd like to avoid coding up beans that for all intents and purposes are the same but one is used in the view and one is persisted. Is this practice recommend in Spring?

Thanks,
Andres

[Craig Walls]

Originally posted by Andres Camacho:
The thing that is not clear to me yet is the relationship between the DAO objects and the MVC form objects in Spring. Are they separate? Can they be the same? Does anyone know of a good example that showcases not only the Hibernate side of Spring but also the MVC working together?

As a matter of fact, you can use the same object as a form-backing object and then turn around and call saveOrUpdate to persist it with Hibernate. The cool thing is that the object in question is just a POJO. It's not like Struts where you have an ActionForm and then have to translate that to a POJO (or worse, translate it into an Entity Bean) in order to persist it.

And it works the other way around, too. Once you've retrieved a POJO (via Hibernate), you can turn around and put it in the request for display on a JSP.

But, before you get too excited...while you can use the same object at all tiers, that doesn't necessarily mean that you want to. Your persistent object may be quite complex and have several fields...and you may only be editing a few of those on the form. In that case, it may make more sense to have a slimmed down version of the object and still do the translation.

At http://nfjs.habuma.com/Pizza.zip, you'll find a simple demo application that I use when I speak on Spring. It does things both ways with regard to sharing objects between persistence and MVC layers. In some cases, I have a separate "command" class that is a skinnied down version of a larger persistent object...in other cases, I use the same object across the layers.

Be sure to read the README file in detail, as it has some important notes on building the app.

[Andres Camacho]

Thanks I'll check it out.