Skip to content

Instantly share code, notes, and snippets.

@tamlyn
Last active January 24, 2024 16:44
Show Gist options
  • Save tamlyn/86bb472e12f4aacd38a0b9f77e8509d6 to your computer and use it in GitHub Desktop.
Save tamlyn/86bb472e12f4aacd38a0b9f77e8509d6 to your computer and use it in GitHub Desktop.
The case against ORMs

The case against ORMs

My experience of ORMs goes mostly as follows:

  • you have to write your queries in the proprietary DSL but that's OK because there's lots of documentation you can read to learn how to do the things that you already know how to do in SQL
  • inevitably some queries are not possible in the DSL but that's OK because you can also run raw SQL queries through the ORM
  • when running raw SQL queries you lose type safety and the 'mapper' part of the ORM is no longer automatic but that's OK because there's an API to let you specify the types and the mapping yourself
  • lazily loading associated entities is too slow but that's OK because you can specify up front which related objects should be fetched from the database
  • when dealing with large amounts of data all the instantiated classes take up too much memory and kill performance but it's OK because you can specify that you want data-only objects (without methods)

Once you've worked around all the problems introduced by the ORM, you find you're no longer using any of its features.

When a complain about ORMs, someone always pipes up with "ah, but have you tried ?". That in itself is a red flag: the reason there are so many ORMs is that they're all crap.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment