Agreed ORM's are usually very sub-optimal. They make sense only because application developers aren't db people. And this is the problem.

I suspect for certain parts of some apps, ORM's might work OK. But in general for applications of any complexity they will break down hard and fast, and lead to bad db design, bad performance, or both.

ORM is just less work. If you write in OOP you are already creating objects anyways. Then writing get, save, and update procedures is just a lot of extra work.

The problem is then you build databases around your ORM but if you are doing a single app database, why use an RDBMS at all?

In other words, I see an ORM as an antipattern because the subset of cases where it works really well at bridging the gap you probably don't really want an RDBMS in there anyway.

And if you do make it work (encapsulating your db behind updatable views) without running into this, it's a heck of a lot more work than hand-coding SQL.....