title: LINQ to SQL, ExecuteQuery, etc
body: <p>This might all be a bit subjective:</p>
  
  <p>Our organization has made a strong attempt to adopt LINQ to SQL as our primary data access method and for the most part this works well. (Let’s leave the EF out of the discussion.)</p>
  
  <p>Some of our developers find LINQ difficult and migrate back to traditional raw SQL via ExecuteQuery. We also utilize OpenQuery in some of our applications to access data on remote servers. OpenQuery cannot be executed via LINQ and always results in code being executed via ExecuteQuery. As an organization we have also made the decision to move away from Stored Procedures and again relying on LINQ.</p>
  
  <p>So, is it fair to say that some queries are just so complex that they can’t be performed with LINQ? We want to avoid business logic in the database so where do we go when you can’t use LINQ? What is the general feeling of ExecuteQuery as a better alternative to ADO.NET Command.Execute()? I think one can make an argument against stored procedures or a the very least that avoiding them is a valid choice but what about querying Views with LINQ as an alternative?</p>
  
  <p>Thoughts on where to land the plane on this? What are others doing?</p>
  
  <p>Thanks,</p>