[temporallobe]

> We’ll use an ORM to do data access because we don’t know SQL

I’m no database engineer, but the whole point of using an ORM is to avoid bare-bones SQL. It’s generally accepted that using an ORM as an abstraction on top of the data layer is a more maintainable solution. At least that’s what we’ve been taught. However, I do believe in writing and knowing actual SQL (for whatever target DB you’re using) so that you can understand what’s actually happening “under the hood”. And many ORMs allow direct SQL passthrough for optimizations, however having an ORM for basic queries like selecting values from a table or view are very welcome and I will always advocate for their usage. I don’t see how this incurs technical debt - in fact I would say just the opposite. NOT using an ORM induces technical debt.

[kwhitefoot]

> It’s generally accepted that using an ORM as an abstraction on top of the data layer is a more maintainable solution.

Not in my experience. Unless there has been a radical shift in opinion in the last five years I would say that that was quite a controversial position.

[temporallobe]

I’m willing to admit that perhaps I’m a victim of the Availability Heuristic, but for any Enterprise application I’ve worked on in the past 20ish years, an ORM has almost always been used and in my opinion they has reduced the a lot of the tedium. I wasn’t intending to debate whole ORM vs. SQL thing, but my point is that I don’t agree that using an ORM necessarily incurs technical debt. I also take issue with author’s assertion that ORMs are used because the developers don’t know SQL, as if to say that the SQL-only approach is the valid one, or that developers who use an ORM don’t really know SQL. See also: TypeScript vs. JavaScript, SCSS vs. CSS, etc.