I believe in ballance,
you need the query builder for simple queries (that makes most of your queries)
but the complex queries should be also supported (even if they are not portable)
We have written exactly this kind of ORM https://github.com/holdfenytolvaj/pogi
It saves you a lot of code writing, but is not taking away the power of postgresql (however it is anchored to postgresql)
I have no interest in automatically building relationships, I'm completely fine doing that manually, or not at all. Which is why dapper is probably my favorite DB solution out there.
return conn.query<MyKlass>("select * from my_klass_table where status = :status", new { status=myStatus }).ToList();
The only thing that can be bothersome sometimes is inserts and updates. It would be really nice to have something that could auto-generate the SQL for you. var sql = SQLGenerator.insert(MyObject);
or var sql = SQLGenerator.insert(MyObject, MyKlass.InsertableProperties);
It would take care of one of the downsides of raw SQL, which is schema updates needing to be dealt with in multiple places, and would remain super simple.I mean hell, if you wanted to get fancy you could create a generator that would figure out the columns necessary by reaching out to the DB the first time and caching it afterwards, and using a naming convention to map to the actual properties. But personally, I'm 100% fine not having that.
I feel like Im not really the type that wants an ORM to take care of SQL or relational functionality, all I really want is an object mapper at the edges, going in, I want to pass an object and have it map into the right fields, coming out, I want it mapped to the right place.
Doing stuff like preloading or relation loading should be done through convention or by database schema querying.
Its a tricky problem to solve, while some relational mapping is super helpful to prototype it almost always results in a mess down the line where just writing SQL upfront prevents pain later.