dortiz

First of all, you can't do ORM without knowing SQL it's an inherently leaky abstraction and that's not changing anytime soon.

Using SQL is great except what do you define as 'SQL'. Is it MySQL, Oracle or Postgres? How do I migrate between them? Forget data migration, I'm just talking about the data model and constraints. Today I run my app on MySQL but tomorrow the environment will demand Oracle.

I have an app that can run on any database that Hibernate supports with zero code changes and 1 line in a config file including my data constraints.

This author doesn't know ORM, plain and simple. ORM has serious limitations and we can all agree that it sucks some of the time but a lot of the suckiness depends on the tool. If you use a crummy ORM expect crummy results. I could go on for pages and pages about what a good ORM can do but I'll just try and sum up my experience with Hibernate.

On the whole Hibernate is awesome. Yes, it has it's warts and it's very complex sometimes but once you make it a part of your infrastructure it's fantastically good. Using Hibernate with sane session management and second level caching gives on the average much better performance than would otherwise get on of hand written SQL. A good hibernate caching strategy can keep you from hitting the database at all and the best part is you just turn it on and go. If you need more performance you can use views and stored procedures for the maybe 1% of cases that can benefit from them.

Lazy initialization is a godsend for complex object graphs and HQL makes complex joins extremely readable and a breeze to write. . The biggest knock I have on Hibernate is that it's so easy to use poorly. No matter how much documentation is on the Hibernate website people insist on using it poorly.