I couldn't agree more. I am currently working on a .net/SQL Server app which uses Entity Framework/Linq (not my idea) for 98% of the data access. The SQL which is generated as a result of the Linq queries is basically a massive bunch of union statements which returns a kind of pivoted data dump of every entity and every field. The query runs quickly enough but shifting this massive result set across a slow network can be very slow.

Give me SQL written by a competent developer any day. In the world of migrations using VS2012 and TFS (convoluted in a large development project) stored procedures can be easily amended in an emergency hotfix scenario. Speed of delivering fix to customers matters as much as strict configuration management.

The whole justification for EF seems to be

I) EF always writes better SQL than developers ....that may be the case for bad SQL developers but not good ones

2) EF makes it easy to change RDBMS. Maybe, assuming the app has good separation of concerns, but how often does anyone actually decide to change from SQL Server to Oracle etc

3) EF makes it easy to map from database entities to objects, esp if you use automapper or similar. I'd agree with that.

I am a big fan of manipulating and querying data on the database server unless there is a good reason not too.