Posted by eitan
on May 5, 2005 at 11:29 AM PDT
i've been meaning to write about my impressions/experiences with hibernate for a while now. for some reason i've been putting it off..until now.
i've been meaning to write about my impressions/experiences with hibernate for a while now. for some reason i've been putting it off..until now. i've been using hibernate for maybe a little over year. i'm still using the latest 2.x implementation (i haven't yet had/taken the time to migrate to v3.x). in reflecting about hibernate over this period of time, a number of its characteristics have really struck me, impressed me:
- i find the hibernate api does an excellent job of making sure that the concerns of the api do not leak into the client application. the primary authors of hibernate (gavin king, christian bauer) stress this important issue in their book . i believe they were really true to their word with respect to hibernate.
- o/rm apis by definition are a layer on top of the database's own interface; they act as a buffer and decoupling layer between your code and the database. sql is one of those staple technologies that would never go away because very few o/rm apis were able to successfully supplant it. i find that hibernate has been able to do just that: with hql and its other mechanisms of querying a database (e.g. the criteria api), hibernate has successfully taken root and i believe is on its way to supplanting sql.
- i also find hibernate to be true to the mantra of keeping simple things simple and making more difficult things possible. that is, for most things hibernate mapping files work very well. however, if you have more complex situations, there's usually a way for you to plug that behaviour in to hibernate via its various interfaces. the examples that i've used, that come to mind at the moment are these interfaces: UserType, CompositeUserType, and PropertyAccessor.
i realize that such features have become more the norm than the exception these days, but not only do these extension points (and others) exist, but i've found them to work well in practice.
there are other features in hibernate that i've resorted to as i wanted to model more complex or special relationships and each time i've been pleasantly suprised that i was able to make things work the way that i expected them to. Here are some examples:
- although it's discouraged, I find "any" type mappings wonderful, and the same goes for many-to-any type relationships. that's what i use to model relationships betweeen types that don't follow an inheritance model, but rather an interface model.
- I also leverage hibernate Components extensively for modeling composite/aggregate types and have had good success with it
- I have been able to leverage the criteria api to the max. from the hibernate documentation i infer that there are two camps when it comes to a preferred query api. quoting the character 'tuco' from the film 'the good the bad and the ugly': "there are two kinds of people in this world my friend, those who like hql and those who use the criteria api." :-) anyhow, what _i_ particularly like about the criteria api is the fact that it has a one-to-one mapping/correspondence with the way one would model a query in a gui. i am _very_ "big" on having (or being close to the ideal of) a one-to-one mapping between guis and their underlying object model.
so, in a system that i'm currently developing i have generic query gui capabilities built right on top of the criteria api and it works like a charm: against any of the types in my business model.
many folks in the hibernate community were waiting for projection features which were delivered with v3. this is one of the main reasons that i will eventually upgrade to v3. for now i'm pretty happy with an unofficial patch to 2.x that gives me a simple but essential feature: Criteria.count()
so i really want to give kudos to the people behind hibernate who imho have produced a really terrific o/rm solution. i haven't even brought up caching or the myriad of hibernate tools or the fact that concerns such as sql dialects are becoming a thing of the past thanks to products such as hibernate.
i'd also like to touch on is hibernate, the open-source project. there are many open source projects out there.. and in terms of their success they span the whole spectrum: from entirely obscure to wildfire adoption. very few have had wildfire adoption and hibernate is one of those few projects. there's a tremendous community behind hibernate. being able to make that succeed is not easy. it's too hard to try to explain what secret ingredients go into making a successful project and the hibernate project web site discusses what they think the right recipe was for them (see why is this project successful ). i'm not going to say that hibernate is necessarily a model example to follow. it's a fairly difficult and complex question to analyze: what makes a project successful? oftentimes the reason is that the project tackles a serious and very common problem that 99% of us have. so, a terrific solution to something that is not so much of a problem will likely never reach wildfire adoption. nevertheless i agree that it never hurts to do the things the hibernate project team does: reply to questions on the mailing list, listen to your users, fix bugs quickly, have excellent supporting documentation, web site, wikis, forums, and much more.
lastly, it is not my intention in this blog entry to even have an opinion on the whole debate regarding jdo vs hibernate vs other orms. i simply am discussing an api that i happen to have picked and used and have gained experience with.
i'd be curious to hear how your experiences with hibernate compare to mine. thanks.