Several years ago at the point in time that Microsoft was introducing Linq to SQL an architect of my acquaintance was so enthralled with the technology that he immediately used Linq to SQL on an enterprise production application. Everything worked fine until the first patch came out for the framework. His application blew up the day after the patch was installed. It seems the patch converted an inner join to an outer join and resulted in several records being returned instead of one.

My own experience goes back to DAO,RDO and ADO prior to ADO.NET. I learned way back in the '90s that you cannot trust Microsoft technologies that cross platforms. If I have any influence on a project, I will not use the controls to update the database for any reason. I want to have lean and not fat code in my applications and I wan to be able to trace what the code is doing.

I was recently an architect on a project for a bank and the developers wanted to use the Entity Framework in the data access layer. They wanted the latest technology, I wanted a light weight data access layer; as architect of the project I won the argument. The easiest way to deal with this issue is to require a performance test of the new technology versus the use of stored procedures. In my experience stored procedures always win.