spring's api wrapping
What I don't like about Spring Framework is its api wrapping of existing libraries with spring-specific one. For example HibernateTemplate. I would prefer working with hibernate api directly and I know I can. Thanks to it, I needn't learn the next api and can work with hibernate utilizing its api without any mediator between. Of course in mentioned situation I loose spring's exception hierarchy related to orm frameworks, but always can translate them using aop (or use try-catch inside method, but it's not recommened). But is it important? How often we change orm frameworks. Not so often.
posted by blog master @ 3:48 PM
3 Comments:
hmmm...does spring jdbc support makes things easy? For me it is as complicated as jdk jdbc.
Some things it is doing pretty well and some of them I don't like (e.g. HibernateTemplate which doesn't give me any advantages comparing to hibernate api).
I know I'm a couple of days late, but I thought I'd chime in anyway. First, when you use Spring's Hibernate support, there are a number of convenience methods that make the simple operations very easy to do. In fact, if you were using the plain Hibernate APIs a lot, I think you'd find yourself writing these same convenience methods. However, when you do want to use the plain Hibernate APIs there a number of ways to do it.
First you can use the HibernateTemplate with a callback. This callback gives you access to the raw Hibernate Session that you use when accessing Hibernate directly. The advantage to this particular style of Hibernate usage is that you still get all of the exception hierarchy translation, transaction participation, and generally all of the advantages that Spring gives you in the convenience methods but allows you free reign to do anything that Hibernate can do.
Second, you can actually do the same kind of thing without using a callback. In this case, the HibernateDaoSupport class provides you with a reference to the current session that you're using (with the getSession() method) that participates in transactions properly, but in this case, you'll have to manage the exception translation yourself. This isn't as bad as it seems though because the DaoSupport class provides a method called convertHibernateAccessException() that will do the translation for you.
Third and finally, you can implement your DAO with the plain Hibernate APIs directly and still have them participate in Spring managed transactions. This has the advantage of not having a single Spring import but doesn't have any of the exception handling behaviors that you'd get from Spring normally. This is certainly a viable option if you're very concerned about Spring imports, but generally isn't a nice as the other two choices.
So generally, what we see with Spring users is that most of the time, they extend HibernateDaoSupport and use getHibernateTemplate() with the convenience methods when they can. When they need something a bit more powerful, they go to the first choice which allows them to use the whole Hibernate API but still get all of the transparent transaction and exception support.
As I said before, your concern about the simplified API is certainly valid, but you'd probably write the same simplified API if you were using Hibernate extensively. Then the question really becomes, should you? Does infrastructure code that you have to write and maintain bring any value to you or your customers? Probably not. Instead let Spring handle the infrastructure for you and focus on your business logic.
As you can see, Spring does try to make the simple things simpler but we will always give you a way (and many times more than one) to access the full power of the technology you've chosen.
Well Ben...
According to DRY principle I am still against mirroring API. Personally, I prefer Hivemind attitude where we deal with plain Hibernate API.
The exception translation should easily be done using AOP since Hibernate 3 has runtime exceptions (does anybody start new projects with Hibernate 2?).
Anyway, thanks for your vital suggestions and taking the voice in the discussion.
Please, keep reading my blog;)
Post a Comment
<< Home