> 1. They pretend SQL is standardized, and support a heavily reduced featureset for any given database as a result
EF Core is provider-specific and also exposes provider-specific functionality.
> 4. You end up not wanting to use the objects directly anyways, so you end up with object-object-relation, needing a mapping layer from your database-object to your business-objects, which also defeats most of the benefits from change-tracking
> 5. The generated SQL is periodically utterly nuts, so you have to review every generated query anyways
Not universally true either. You only have to review complex queries. If you're making claims about a specific ORM it would be good to mention it as it's not universal.
> 6. You probably dont want to actually use any of the OOP mapping features like inheritance in your DB
Then don't? Since when is inheritance required for ORM-usage?
I have found a lot of the anti-ORM critiques come from either using a crappy ORM or having not used a good one in the last 5 years.
EF Core is provider-specific and also exposes provider-specific functionality.
> 4. You end up not wanting to use the objects directly anyways, so you end up with object-object-relation, needing a mapping layer from your database-object to your business-objects, which also defeats most of the benefits from change-tracking
This just isn't true for EF Core. https://learn.microsoft.com/en-us/ef/core/performance/effici...
> 5. The generated SQL is periodically utterly nuts, so you have to review every generated query anyways
Not universally true either. You only have to review complex queries. If you're making claims about a specific ORM it would be good to mention it as it's not universal.
> 6. You probably dont want to actually use any of the OOP mapping features like inheritance in your DB
Then don't? Since when is inheritance required for ORM-usage?
I have found a lot of the anti-ORM critiques come from either using a crappy ORM or having not used a good one in the last 5 years.