Have you actually read TFA? Fowler's point is that yes, ORMs don't solve all of the really hard mapping problems, but save you a lot of boilerplate on the other 80-90%, and the hallmark of a good ORM is that it allows itself to be bypassed with relatively little hassle for those hard problems (like performance tuning).

Also from TFA: what do you suggest using instead?

Come on - how hard is it to write

"select id, username, email, nickname, date_registered, pass_hash, first_name, last_name, middle_initial, home_phone, mobile_phone, work_phone from user where username=?" and manually do escaping whenever you want user info?

You seem to be suggesting that

user.findByUsername('joe')

is somehow more worthwhile or usable. It's certainly more noble, because an ORM doesn't solve 100% of a set of problems 100% of the time. OBVIOUSLY it's better to never use them, ever. In any circumstance.

"select id, username, email, nickname, date_registered, pass_hash, first_name, last_name, middle_initial, home_phone, mobile_phone, work_phone from user where username=?"

is really more readable because I always want to know every single piece of data, and read it every time I look at code (and update all my SQL queries every time I make a schema change) all the time. I'm finding that my monitor is often devoid of code - I have too much space on the screen just begging to be filled up with useful boilerplate code so I don't ever forget all the column names in every table.

copying my answer from virtually the identical commentary made on reddit ("why should I use an ORM when I can just write the SQL?") (not to mention Fowler's article makes this same point pretty clearly):

ORMs do not claim to be "simpler than SQL" and this has nothing to do with the purpose of an ORM. There is nothing that's ultimately "simpler than SQL", if in fact you aim to just write SQL.

The purpose of the ORM is to marshal data between an object-oriented domain model and a relational schema, to translate a wide array of common relational patterns with corresponding domain-model patterns (think foreign key to collections, for example), and to express relational queries in terms of the object model at least to some degree.

All of this is well outside the realm of just "writing SQL queries". The ORM is a tool used to integrate relational databases with an object oriented application layer, and to that degree they make this task a lot less effort than doing it by hand.

You pretty much nailed what I was going to say. Yeah, I found it a bit strange that the only alternative to using an ORM that the author could imagine was to roll your own? What's the problem with using SQL directly?

To answer the grandparent: I did read TFA, and I don't buy it. His claim that a good ORM makes 90% easier and gets out of the way of the remaining 10% doesn't match my experience with any ORM at least. Perhaps I'm wrong! All I'm saying is that from what I can tell, using an ORM buys you nothing worth buying.

edit: Ha, you're being sarcastic. No, I'm serious. Are you saying that using an ORM solves escaping problems? I honestly have never connected those two. That to me is a problem calling for a set of escaping/unescaping functions, not an object-relational mapping. To each their own...

I'll try to clarify what I mean, since my reply to the other post is somewhat confused. I should read more carefully before posting. Anyway.

First of all, is your data suitable for storage in a relational database?

If not, if you end up having to do tons of joins and every table has references to other tables, something like Redis is probably a better fit - I'd move away from ORM/relational at that point.

If it is, then what does using an ORM buy you? Simple queries are simple to write and maintain, so in my experience you don't gain much there. More complicated queries are not handled well by any ORM I've seen, so there you'll want to write them in a relational language anyway.

So, at least the situations I've had come up have both resulted in moving away from the ORM, either to a non-relational database or to keep the data in a relational-friendly format. A lot of the nitty gritty of writing relational queries by hand (as noted, escaping, listing the fields to be queried etc) can be abstracted by a set of helper functions, and maintaining these is much simpler than fixing problems with the relational mapping. For example: you have an inefficient join. Using an ORM, you'll be solving this problem indirectly either by massaging the ORM or bypassing it entirely. If your join is directly expressed in SQL, you solve the problem by modifying the join. There's no additional headache involving figuring out how the object model turns into tables and queries.

Data that's not a good fit to be represented as relations is a completely different issue, and I agree with you on that.

Simple queries maybe simple to write, but they're still boilerplate you're better off without. An ORM lets you work at a higher level of abstraction.

> A lot of the nitty gritty of writing relational queries by hand (as noted, escaping, listing the fields to be queried etc) can be abstracted by a set of helper functions, and maintaining these is much simpler than fixing problems with the relational mapping.

Except that you just started to roll your own ORM, and I can guarantee that maintaining it will not stay simple for very long.

> If your join is directly expressed in SQL, you solve the problem by modifying the join.

Yep, that's what you do with a good ORM.

>There's no additional headache involving figuring out how the object model turns into tables and queries.

Wrong - as long as you have a relational DB at one end and an object model at the other, this additional headache is unavoidable.

The problem is there's plenty of trivial work for an ORM to do (mapping types, simple queries, etc). If you roll this yourself your implementation will be buggier than a major open source ORM.

Yeah. The mismatch between how devs expect to use the ORM, and how the ORM expects to be used, causes enough problems in my experience to make the ORM not worth it in the first place. I'm tired of seeing crazy-long NHibernate stack traces and exception descriptions because, like, a column got altered.

Writing data-retrieval code is tedious, and nerds always want to automate tedious things. But sometimes the cure is worse than the disease, and the effort to eliminate one type of tedium gives rise to a new, fancier kind of tedium.