To Hibernate or not to Hibernate that is the persistence question! Whether ’tis nobler in the mind to suffer the slings and arrows of outrageous SQL statements Or to take arms against a sea of result sets and by opposing iterate them?
This post is about my ambivalence about the Hibernate framework and its frequent partner, Spring. Proponents will tell you how it simplifies service layer calls to persist objects; allows a developer to think more completely in objects, and leads to a reduction in lines of code and inadvertent developer errors in persistence routines. The part of the equation that is often neglected is what it takes to design and configure a robust and usable Spring-Hibernate architecture.
These frameworks aren’t for the faint of heart – yes, if you’re walking into a gig where the architecture is already in place and the bugs are mostly ironed out; and, the team has bought or developed expertise in these frameworks, then using these frameworks is manageable and at times even easy. However, if you’re new to these frameworks and working on a project that has to ramp up quickly, design decisions can easily be made that make it challenging and time consuming to figure out how to do what you need to get done and how many configuration files you’ll need to do it.
Moreover, Hibernate now supports JPA annotations – which saves some time perhaps in that persistence strategies are visible in the entity model classes, however, learning the annotations is can be as challenging as learning how to set up the hbm.xml configurations. I’m not arguing that Hibernate isn’t powerful, on the contrary, I think there are lots features that allow inheritance or cascading across a class hierarchy to be succinctly expressed. The open question for me is whether or not the time and effort required to learn these features and their annotation syntax, limitations, edge cases, etc – really in the end results in a faster time to market or a more maintainable, flexible architecture.
This is a tough case to prove either way. My own experience over the last few months working with Spring and Hibernate is that once I learn something well, I feel like I’m saving time and effort. Unfortunately, since I have no parallel universe to experiment in, I’m hard pressed to say that writing the equivalent SQL and iterating a result set wouldn’t be faster for me to do an ultimately, more understandable when I have to maintain or enhance the code 6 months from now. I wasn’t around when the schema was developed but I think it is fair to say that a simple schema and transaction strategy can be implemented in a simple way using Spring and Hibernate, the problem is that real production applications rarely stay simple for long and as they morph to handle a broader and more varied problem domain, one’s expertise in Spring and Hibernate has to grow accordingly.
As heretical as it may seem to some, a viable alternative in my mind is to eschew these frameworks from the start and focus on gaining expertise in SQL; understanding the structure and performance quirks of your database implementation, and working with a UI toolkit (GWT or Vaadin) that doesn’t also impose the overhead of learning a bunch of arcane tags and strategies (JSF comes to mind). Of course, there are always new ways to do things in IT, I’m just leaning towards the possibility that simpler (even if it entails some redundant coding of JDBC calls or prepared statements, etc), would in the end be preferable. I’d rather rely on SQL than an abstraction layer that I can’t really change or optimize.
As I gain more experience and confidence with Spring and Hibernate, I can imagine my views changing somewhat but in the meantime, I keep asking myself, are all these layers and frameworks serving me, or me them?
