This piece resonates very well, as it mirrors my experiences about EF, yet I’ve also had issues with Dapper, and have not tried OrmLite, partly because its license. At work we ended up using EF, but I came to hate most of its batteries included features, and for my personal projects I always go with Dapper.
note: we had problems with concurrency in Dapper, as its static parts did not always initialize correctly, but had no time to fix them as they were in a legacy module already being replaced, and we had a deadline approaching rapidly.
I occasionally wonder if IDE integration and static analysis can do away with many ORM things. IntelliJ can already make sure my SQL is correct and refers to things in my Dev database. If it were aware that x['id'] is legal given x derives from some select statement I’ve written in psycopg2, will I already have eliminated the class of bugs that micro ORMs catch? And enable the class of programming style that they enable?
The effectiveness of Active Record for me comes from the autogenerated code that makes it easy for me to migrate, marshal/unmarshal, etc. If I have to write value types for everything then I could just as well get close to pure statements and use a dictfactory for my cursor (using python psycopg2 lingo).
Then again, there’s always SQLx
F# also has type providers which is probably slightly more appropriate for the ecosystem (dotnet) with similar compile time checked queries.