[WkndTriathlete]

Agreed on the N+1 query problem, but I'm a bit mystified why people still choose ORMs for any projects with even a moderate level of database complexity. When using a straight SQL layer (JDBC or the basic features of KISS-orm) the query is in SQL form and the performance characteristics of the query are obvious from the query or can be analyzed easily by taking the query and running it through the database's query analysis tools. Using an ORM just adds extra steps: instead of optimizing a query in SQL, the query needs to be optimized using directives or methods or annotations that the ORM provides in the hope that the SQL that is ultimately generated is efficient; that is, we're programming the ORM which programs the database instead of just programming the database. Why bother with the extra step? With modern programming languages there really isn't that much extra boilerplate to implement the DTOs for straight SQL and it usually results in code that is a lot easier to maintain and extend in the examples I've seen.

[Dragory]

In my experience, 99% of the relationships I fetch fit the basic one-to-one, one-to-many, many-to-many definitions that pretty much all ORMs support. For these cases, the queries are generally more than efficient enough and there's little reason to reinvent the wheel and implement the code for fetching those relationships yourself.

For anything more complex, I agree. But for the common case of fetching simple and often (depending on your project) nested relations, I definitely enjoy the abstraction provided by ORMs.