What are some pros and cons of using linq over stored procedures?
I was talking about this with someone here the other day, as we use stored procedures for all database access currently. We were discussing LINQ in general, and the LINQ to SQL implementation, IQueryable etc. She quickly realized that using LINQ with sprocs would be redundant at best and difficult at worst.
The advantages of LINQ to SQL are that the code lives in one place, and what is occurring in the DB is very clear. In addition the development time can be less, depending mostly on process, as there is one less work product to make.
The advantages of Sprocs, as I see it, are also twofold. Stored procedures allow for much better access control for a DBA, as they can inspect the sproc before deployment, and allow the application use access only to execute that sproc rather than read/write access to all the tables required. This makes for much better reviews of database contention and performance issues. The other advantage I see is that while LINQ to SQL will generate a correct query, in the case of complex queries there are times where you hit a case that causes poor optimization on the DB end. In those cases you would either rewrite the query, or provide hints to the optimizer, both are difficult/impossible/metaphor breaking with LINQ.
Maybe it's the DBA in me(not a DBA, but have been), but I feel really nervous when working on a large high transaction load DB and not knowing exactly every possible statement that would be executed by a system. So I'm sticking with sprocs myself.