I've found that the problem with not using an ORM is that you can end up writing a lot of repetitive CRUD queries. Every model ends up with the same basic read, insert, update, etc. function, but because you're writing untested, un-typechecked SQL queries, they still need to be carefully reviewed, tested, etc. You can write some helper functions to abstract over the repetitive parts, but then you start creeping into home-grown ORM territory, which is much worse than using a standard battle-tested ORM. If I'm using a ORM, I can be pretty confident that the method to read my model using an ID is going to work without fuss.
For a small service with just a few basic queries, skipping the ORM and going straight to SQL is pretty nice. And there are situations where you need custom SQL, like complex reports or dashboards. But for typical CRUD in a team setting, I've found that ORMs can be worth the overhead.
No. Classical fallacy: not using an ORM does NOT mean writing raw SQL strings. You can still use a library that helps will all the SQL specifics and even checks your schema for you at compile-time and help you abstract over common logic/operations.
Hello! I've been looking for a library like this for C# and another for Python - I'm not sure which terms to Google to find them!