This might all be a bit subjective:
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.)
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.
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?
Thoughts on where to land the plane on this? What are others doing?
Thanks,
Use the right tool for the right job. Linq-to-SQL covers a large portion of what you need to do on a daily basis in a typical line-of-business app – so use it there. Devs will get used to it, and will probably also begin to like it – it’s really quite powerful and useful!
But yes – there are defintily scenarios where a straight-up SQL query will be a lot easier to use – that’s fine, no harm done – that’s what ExecuteQuery is for. If you have a bunch of CTE’s and complicated joins of various types – you might be able to express that in Linq-to-SQL, but it might be just too much effort and hassle to do it if you already have a T-SQL statement that works….
It takes time to get used to a new way of doing things – give it some time! I’m sure most of your dev will migrate to LINQ step by step. Encourage them, give them tips & tricks, help them where you can. But also accept that in same cases, tricky SQL statements might just be too tricky to rewrite in LINQ (if you already have them and they already work – just keep using them).