Yeah, but from what I saw it doesn't help much with master-detail setups? Like, inserting or updating an order with order lines etc. We rely heavily on those.

It is pure SQL, so it should, I think?

Use transactions => fails rollback. No need to correct failures.

Important concepts: .NoTracking and setting the EntityState correctly ( mark as deleted, updated, ... )

Additionally, sometimes it's easier to update things granularly, instead of all at once.

I suppose the annoyance comes from updating in bulk on a POST and trying to map everything?

Maybe also check PetaPoco. But at this point you're getting closer and closer to code-first EF Core anyway. :)

https://github.com/CollaboratingPlatypus/PetaPoco

I haven't actually tried either Dapper or PetaPoco, only perused their documentation. But I was sold on LinqToDb after seeing how it supported CTE and seeing our close code to generate updates [1] and joins [2] ended up looking like the actual intended SQL.

  [1]: https://linq2db.github.io/#update

  [2]: https://linq2db.github.io/articles/sql/Join-Operators.html

"seeing how close"

It can. Basically you separate the query response by the parent and child in the row using `SplitOn` and it can materialize it.

I use the ORM with Servicestack, OrmLite, and it seems to handle those 1 to many references well.

https://docs.servicestack.net/ormlite/