Disadvantages of Hibernate ?
When googling disadvantages of hibernate, you would find lots of discussions and arguments as to what works and what not in hibernate. This is year 2011 and Hibernate 3.2 has been released . An an ORM framework it has matured a lot . I will sum down my experience of working with hibernate so far
1. If it is a small project with few tables , I think there is no need for a full fledge ORM framework like hibernate. You can very well using Spring with JDBC and keep complexity to minimum.
But this is a classic mistake made by teams initially. You assume that the project will have only 3-4 tables and few updates and inserts, but as and when you gather requirements, dive deep into design , add more features, it starts to get bigger.
At later stage you wishes you had started with ORM framework else you might have to write all the inserts, updates and selects which is a huge waste of time ,considering all this can be configured easily by hibernate.
2. Performance : A lot is being talked about hibernate performance. We have used Spring and hibernate with one of the biggest deployment in clinical applications and I can tell you, I have not seen any issues or so because of hibernate.
Yes we had to fix the hqls at few places but that is a normal tuning process.
3. Hibernate is slow because it uses run time reflection: People who had faced performance issues with reflection in early ears were skeptical about hibernate’s use of reflection. But not anymore. You should not worry about performance loss due to reflection. From hibernate’s doc
Modern JVMs implement reflection extremely efficiently and the overhead is minimal compared to the cost of disk access or IPC. Developers from other traditions (eg. Smalltalk) have always relied upon reflection to do things that C/C++ needs code-generation for.
In the very latest versions of Hibernate, “reflection” is optimized via the CGLIB runtime bytecode generation library. This means that “reflected” property get / set calls no longer carry the overhead of the Java reflection API and are actually just normal method calls. This results in a (very) small performance gain.
You can always hancode sql’s at places where you think it is going to be complex scenarios and a native sql would perform much better. But this is required rarely , so this is an exception , not a rule.
4. Composite mapping is complex : If you do not understand it , yes it is complex . But this will not be a disadvantage. We have talked about this here mapping composite keys in hibernate.
3. Everything is returned as object : Yes that is true and even if you would like to get an id or name, you would write the hql and get an object which has the complete data set. This is anyways not bad because while designing methods, you will have coarse grained objects which well be returned. I would not prefer to return String or int from my methods.