A decade ago I was first introduced to servlets. It was a revelation. Prior to that I (like most people) had been doing CGI scripts (in Perl and even C and C++). Suddenly we had something that persisted between requests. Combined with JDBC you had a pretty powerful platform.
In 2001 or so began the madness that was the Java world's love affair with EJBs. I came into it at the EJB 1.1 stage with EJB 2.0 just on the horizon. A consultant at the time decided it was a good idea to write a logging service as an entity bean. It took roughly half a second to write a log message!
This began my questioning of and ultimate departure from the EJB. Going through 2002, cracks were surfacing. It became widely accepted that EJBs weren't suitable for high throughput applications. The pro-EJB crowd argued that EJBs weren't suitable for all applications but that shouldn't mean you dismiss the technology.
Experience has taught me that when someone wheels out this argument of selective observation that it's a huge red flag.
Apart from stateless sessions beans, which are a fairly cheap and effective way of getting distributed transactions in a clustered J2EE environment, EJB (pre-3.0) was basically a bad idea.
By this stage J2EE had started to fracture. Soon would come Spring, which would change the Java server landscape forever. The other big change was Hibernate.
Hibernate became the poster-child for post-EJB OO fanatics. I was late to this particular party. I'd gone back to doing plain SQL and was happy. Less than two years ago I was forced to learn JPA and I gave it a fair shake of the stick, I really did.
The relational-object divide has been a divisive issue for many years. Jeff Atwood went as far as saying Object-Relational Mapping is the Vietnam of Computer Science.
I am a steadfast believer that abstractions are leaky. And an object model on top of a relational model is an abstraction. To jam this into the Java/J2EE world, apparently mechanisms like load-time weaving were required.
Now I believe that those behind such changes were (and are) well-intentioned but, as the quote goes, the road to hell is paved with good intentions. I see the problem like this: imagine a Cartesian graph with one axis representing complexity and the other representing the completeness of the abstraction. The more "complete" it is, the less leaky it is. I picture such a graph would produce an hyperbola. JDBC is simple because it's not much of an abstraction. Hibernate and other JPA providers are incredibly complex because they are attempting to be complete.
There are two corollaries you can draw from this analogy that I think fit:
- To achieve a perfect abstraction the solution would be infinitely complex (ie impossible); and
- There is a "sweet spot" in the middle where a little abstraction has a large reward but, beyond a certain point, there is a law of diminishing returns.
I also believe that every developer should be educated in relational algebra, comfortable with databases and proficient in SQL. Just like any Java Web developer should understand the servlets API before they can truly truly appreciate and properly leverage a higher-order MVC framework like Spring MVC or Struts 2. Ultimately, you still need to know something about how HTTP works. The same applies to SQL.
This is why I believe the effort to create the "perfect" object model for relational databases is futile and ten plus years later we're still not there. And you know what? I don't think we'll be there in another ten years either. If anything, the issue will become a non-issue as the traditional relational database will be replaced by "slacker" databases, persistent caches or whatever comes after that.
Until then, perhaps we should stop trying to fit a round peg into a square hole. SQL just works, it's not that hard and your application will be less complex as a result. That can only be good.
Posts
