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

Yup. I haven't touched .NET in forever ... like it's been 7 years or so but I was there for the 1.0 days. I remember running stuff to code gen db tables to objects and NHibernate and Entity Framework and all that jazz.

I was just like, "wait, why am I writing all of this if it's just a projection". Then the Active Record pattern felt limiting when scaling my application. I think after we discovered Dapper... we just stuck with that. It's a micro-ORM where we write SQL and it maps into C# objects and it just simplified when hydration happens and how. (not sure how much its changed or if it's even active now, but it was amazing)

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.

It's funny, I know exactly zero programmers (and this includes myself) who didn't initially encounter SQL and decide it was clunky and stupid and try writing their own classes to write the SQL for them. I want to think it only took me a few weeks until I understand its actual value and purpose but I'm probably misremembering my past. The worst I ever saw, though, was a coworker who tried writing his own ORM. He had one project with classes named "AND.cs" and "OR.cs". All they did was take an input string by reference and append " AND " or " OR " to it respectively. I'm sure I never before or since encountered a class that did less work.

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