Absolutely, “ORM == bad” viewpoint strikes me as highly ignorant of all the benefits they provide, particularly in statically typed languages.

People like me don’t choose an ORM to save me from having to learn SQL (which you’ll still need to know), it’s because 99% of the time it’s a no brainer as it vastly increases productivity and reduces bugs.

In a language like C#, EF Core can easily cover 95% (likely more) of your SQL needs with performance as good as raw SQL, for the small percentage of use cases its performance is lacking, you fall back to raw SQL.

But if saving you from writing 95%+ of SQL queries was not compelling enough, it’s just one benefit of EF Core. Another major time saving benefit is not having to manually map a SQL result to objects.

But an often super underrated and incredibly valuable benefit, especially on substantial sized code bases, is the type safety aspect. The queries written using LINQ are checked for free at compile time against mistakes in column or table names.

Want to refactor your schema because your business domain has shifted or you just understand it better than before? No problem. Use standard refactoring tools on your C# code base, have EF Core generate the migration and you’re done in 10s of minutes, including fixing all your “SQL queries” (which were in LINQ).

EF Core is almost always a no brainer for any team who wants high quality and velocity.

Totally. ORMs are not evil. They help to reduce the boilerplate and improve the code maintainability.

We have a complex project with a custom back-end framework that also includes a custom ORM. The ORM covers about 95% of the use cases just fine. It reduces a lot of boilerplate and also makes it possible to find the logic much easier (for example, setting and reading some column from a specific table). Although I have to say, it works so well also thanks to good integration with the framework (fronted, included) and advanced features, like calculated fields with automatic recalculation triggering, integration with user permissions, ability to define custom user permission validation logic before / after saving rows, etc. If we really need an unusual operation where the ORM doesn't suffice (most of the time complicated search queries or some aggregation), we can write raw SQL and, if possible, encapsulate it at repository / service level. But 95% of use cases are covered by the ORM (including the management of parent / child relationships).

I think some "old school" folks like to bash ORMs and view them as very limited and inefficient compared to raw SQL. But you can use them both: primarily ORM and in specific cases switching to raw SQL when ORM doesn't suffice.

It’s been swinging for at least 30 years, Toplink came out in 1994, and I have worked on systems that were written half a decade earlier that contained things we’d all call ORMs.

Agreed, ORMs are OK to start with if you like and then optimize the queries where needed.

There are cases where older ORMS might be more optimized for some cases compared to new ones, and vice versa.

Avoiding learning SQL is the biggest gap. Selecting a NoSQL database because it seems easier, and then spending so much time trying to make a NoSQL database into a relational database is usually not too pretty.

Gavin King, creator of hibernate has said many times that you don’t have to use it for everything. Indeed your code can use the entity manager to execute sql. The problem is sql databases are hard, data modeling is hard, it requires a lot of care discipline and even experience (gasp!) to get right.

Edit: Thanks for the merciless downvotes. :)

But it’s a bot writing the above. Look at the user's comment history. "Not x, but y", poorly formatted listicles, mid-paragraph questions to the reader, and em dashes galore.

Everyone too busy writing and posting their "How I use Think for me Saas" / BrEaK It InTo SmAlLeR TaSkS blog posts.

Migrations aren’t necessarily tied to ORMs. There are tons of tools out there to run migrations and nothing else.

Porsager’s Postgres package does a great job of letting you feel like you’re writing raw sql, but avoids the attack vectors.

Anyway, I agree that ORMs are pretty terrible. I like writing SQL or using a lightweight builder like Kysely. Was a huge Dapper fan back in my C# days.

There are plenty of reasonable alternatives to ORMs that don’t open you to SQL injection attacks.

Parameterized queries have been a thing for decades, which mitigate SQL injection attacks.[1] This is true of the examples in the post too, they used this:

  query = """
            SELECT * from tasks
            WHERE id = $1
            AND state = $2
            FOR UPDATE SKIP LOCKED
        """
  rec = await self.db.fetchone(query=query, args=[task_id, TaskState.PENDING], connection=connection)

There are projects, like SQLC, that cover most of the perceived advantages of ORMs, without the downsides.

One of these downsides is, in my opinion, the fact that they hide the very details of the implementation one necessarily needs to understand, in order to debug it.

Yup, sloppy slop-slop

But there's also value gained in it, isn't there? I very much like doctrine's query builders and being able to analyze and manipulate queries programmatically, e.g. dynamically add a filter to a query and a join if needed. That's pretty simple with a query builder once you've gotten comfortable with the concept and the ORM itself, but it's pretty hard to do with plain sql unless you write plenty of specific code to handle all the known things you might care about.

Considering anybody with a noggin is going to be separating the SQL into it’s own module or whatever rather than just throwing straight inline SQL at your database wherever you it, you’re hardly less likely to have things like accidental writes, anyway. This is clearly someone who fell in love with Postgres, felt ORM abstractions that diluted the Postgres goodness were bad, and then did some mental experiments to consider all of the theoretical ways ORMs suck.

I gotta agree with you, total straw man. I haven't seen any of the issues this guy has with ORMs.

I guess I'll bite. How/When do you know you actually need an ORM?

> for the average CRUD-heavy SaaS app, the "boilerplate tax" of writing eighty lines of repository code for a simple related insert might eventually cost more in development velocity than the performance gains are worth.

Perhaps, but IME this kind of thing is much more often the cause of poor performance in CRUD apps than the frontend frameworks that are usually blamed. I have been able to make very snappy SaaS apps by minimizing the number of queries that my API endpoints need to perform.

I've also found that the ORM mainly reduces boilerplate for Insert/Update operations, but often adds a very significant amount of boilerplate for read queries. We ended up using a very lightweight orms for simple inserts / upserts and writing raw SQL for anything else.