> It has never ever been a selling point by anyone with an ounce of brain.
Every project I've been involved with that got saddled with an ORM was originally justified "so junior developers don't need to know SQL".
Which is a great way to paint yourself into a very painful corner, but that's what teams do.
The people who made "not knowing SQL" the main reason to use an ORM should not be making the decision to use an ORM. They can only use it incorrectly.
If there are ORMs that document "not needing to know SQL" as a key selling point of their ORM, they should remove those sentences because it's not.
As someone with 15 years experience using ORMs, you absolutely do need to know how your database works to be effective at using an ORM well. Once you do, and you understand how your ORM works, I still think the benefits of a well-integrated ORM into your codebase make it worthwhile. Generally the code becomes easier to understand, modify and reuse if you're using an industry-standard ORM. Like with most good libraries or frameworks, the number of use cases the maintainers encounter usually means you'll find something pre-prepared when you come across a new problem.
Eventually the Juniors are expected to learn SQL, but until such a time as they do they can still make useful contributions to the code base.
Entity Framework is the best ORM I have ever used. There's no competition in my opinion.
I used to use Dapper a lot, but EF has easily replaced all of those needs for me.
"We use CoPilotPro so that junior business analysts who can't code can still create applications".
Ask chatgpt to generate the schema for an online business that sells sports equipment and see what happens.
Now ask it to write code accesses each table.