Hibernate in the Balance
From Zanecorpwiki
I don't like Hibernate. It's not the worst thing in the world, but it's not a good solution.
Contents |
Before I Begin the Critique, Let's Look at Pros
Clearly Hibernate's implementation quite good. It's a complex system doing things that you really need to take care to get right, and Hibernate does work reliably.
"But what about Hibernate's famed caching abilities?" you say. Well, I'm sure they must be great because there's nothing else good about the system. For all it's efficiency, though, Hibernate sure generates a shitload of unnecessary SQL (turn the logs on). And having written caches and what not myself... it's not that hard.[notes 1]
Design
On the other hand, Hibernate's design is not good. It's no user friendly. The only way to use Hibernate correctly is to understand Hibernate well. In a moderately complex app, you can expect to spend hours and hours trying to figure out why Hibernate makes multiple copies of list elements instead of updating, or why it fails with key exceptions in objects that aren't even involved in the code you're looking at. The errors are useless, the interface opaque, and the detail tremendous.
Documentation
The documentation is not good. The main problem is the docs are written as reference for people that already understand Hibernate. If you're trying to learn Hibernate, they're more or less useless. Even as a reference, they're not very good, either droning on pointlessly[notes 2] or leaving important matters undiscussed or merely hinted at.
There's no good overview of the system. There's no clear description of how things are supposed to work together. There's no delineation between basic, normal and advanced usage. Examples are basic to the point of being naive. There's no cookbook, no best practices, and no guidance.
Harmful Side Effects
Can lead to poor database design.
Too Many Features
Hibernate is feature rich, but hard to use. Hibernate is an order of magnitude more complex than straight SQL or hand-coded DOA approaches. It's harder to implement, harder to maintain, extremely fragile, and difficult to debug. The problem is that all of Hibernate's features are about being able to map a wide range of object models to a wide range of tables in many different ways. The problem is, that's not a good thing.[notes 3]
Summary
Hibernate comes out of a line of "enterprisey" frameworks that try to be all things to everyone. They talk about ease of use, and developers that either A) have a very different experience than myself or B) don't know any better buy into it. But I have to say, I don't think it's true.
Notes
- ↑ General purpose stuff like Hibernate is hard, but writing your own caches is often as easy as a weak hash map with a little wrapper code.
- ↑ Just one example: the 'composite ID' documentation lists three different ways to do composite IDs by fully explaining two methods and saying "but don't do it that way" as the last sentence in each section. The third way (meaning the best way is discussed last) is poorly explained in a separate section.
- ↑ And yet for all that generality, Hibernate can't even deal with collections of collections. Having written my own object data layer, I can attest to the fact that it's not that hard. You handle lists correctly, and just make the processing iterative.
