With the premise that you're in a shop that's open to either... Based on my own experience, stored procedures work better for complex queries or queries that need to be specifically tuned. LINQ-to-SQL does okay generating relatively simple queries, but begins to fall apart when the query gets complex. It also precludes doing any query tuning or adjustment, aside from index creation, without redeploying your code: something that has proven useful time and again in my shop. I'm sure others will have had good luck with LINQ when generating complex queries. Results can certainly vary by environment - it depends, right? :) For a hybrid approach, I seem to recall reading that you can have LINQ-to-SQL use stored procedures, though I'm not sure how gracefully it all fits together. **[Edit]** Here is part 6 of a multi-part LINQ-to-SQL series by Scott Guthrie that covers using LINQ with stored procedures - [
http://weblogs.asp.net/scottgu/archive/2007/08/16/linq-to-sql-part-6-retrieving-data-using-stored-procedures.aspx] **[/Edit]** :
What kind of access to the servers do you have? More specifically, what kind of access to the servers do you have in production? The level of access accorded your application could dictate how you need to do your programming.