Personally, I prefer writing SQL by hand. That way I know exactly what will happen in a query. A database really is an important component of a system and shouldn't be treated like a dumb data store where you just throw in any stuff you like through an ORM and hope it sticks there somehow.
Lots of people do exactly that (treat it like a dumb data store) and are wildly successful. Do what you want, but don't say other people shouldn't do it a different way which has been proven to work.
Certainly. Yet there's been a tendency later to declare SQL wrong and deprecated and to incite everyone to forget about it and go with an ORM as the only way. I do not accept that. The stronger the ORM zealots are pushing the more repulsive the idea of an ORM becomes to me. But of course it's just another instrument that has its place among the others.
Only among the inexperienced. Skilled people use both as needed, even at the same time. You can keep the complex SQL in a view and map the view with the ORM. ORM's are far too valuable to ever hand write all that SQL and SQL is far too flexible to ever ORM 100% of every use case, the ORM should make up most of the program with hand written SQL sprinkled in where useful when the ORM is clunky.
It's easy enough to do that, you don't HAVE to use an ORM framework. Though mapping sprocs to an Entity model is easy enough... I've had to do that several times where performance in EF was particularly bad.
