I only need ORM to have the flexibility of DSL table modeling for repeated fields. Think, createdAt, updatedAt, id (and the PK that comes with it), etc. After the migrations are written, I prefer to use a query builder
Yep… I love writing SQL actually, I find it very elegant and interesting. It wasn’t my original decision to use EF, so I used the incident as an excuse to pivot to raw SQL constants with parameters. Never had another issue. Plus you can just copy paste the SQL into a debugger and directly view the output and optimisation paths. We also had this thing where the first web form request to an instance would take 15 whole seconds as it loaded the entire EF context model and relations into memory, and there was no tricks or traps to fix that at the time. Customers weren’t happy with that answer. Good ol’ SQL though, can’t fuck up that implementation
As long as everything is properly sanitized and parameterized, I agree. Or use an extremely lightweight orm like dapper that basically has you write SQL inline and mostly just does dynamic model binding.
The moral of the story is to always just write the damn SQL and stop fucking around with ORM and frameworks and all of it. 😅
I only need ORM to have the flexibility of DSL table modeling for repeated fields. Think, createdAt, updatedAt, id (and the PK that comes with it), etc. After the migrations are written, I prefer to use a query builder
Yep… I love writing SQL actually, I find it very elegant and interesting. It wasn’t my original decision to use EF, so I used the incident as an excuse to pivot to raw SQL constants with parameters. Never had another issue. Plus you can just copy paste the SQL into a debugger and directly view the output and optimisation paths. We also had this thing where the first web form request to an instance would take 15 whole seconds as it loaded the entire EF context model and relations into memory, and there was no tricks or traps to fix that at the time. Customers weren’t happy with that answer. Good ol’ SQL though, can’t fuck up that implementation
As long as everything is properly sanitized and parameterized, I agree. Or use an extremely lightweight orm like dapper that basically has you write SQL inline and mostly just does dynamic model binding.