LINQ

Disadvantages of LINQ over Stored Procedures

1. Network traffic: SP's need only serialize SP-name and argument data over the wire while LINQ sends the entire query. This can get really bad if the queries are very complex. However, LINQ's abstraction allows Microsoft to improve this over time.


2. Less flexible: SP's can take full advantage of a database's featureset. LINQ tends to be more generic in it's support. This is common in any kind of language abstraction (e.g. C# vs assembler).


3. Recompiling:If you need to make changes to the way you do data access, you need to recompile, version, and redeploy your assembly. SP's can sometimes allow a DBA to tune the data access routine without a need to redeploy anything.

Advantages of LINQ over Stored Procedures

1. Type safety:
   


2. Abstraction: This is especially true with LINQ-to-Entities. This abstraction also allows the framework to add additional improvements that you can easily take advantage of. PLINQ is an example of adding multi-threading support to LINQ. Code changes are minimal to add this support. It would be MUCH harder to do this data access code that simply calls sprocs.


3. Debugging support: I can use any .NET debugger to debug the queries. With SP's, you cannot easily debug the SQL and that experience is largely tied to your database vendor (MS SQL Server provides a query analyzer, but often that isn't enough).


4. Vendor agnostic: LINQ works with lots of databases and the number of supported databases will only increase. SP's are not always portable between databases, either because of varying syntax or feature support (if the database supports SP's at all).


5. Deployment: Others have mentioned this already, but it's easier to deploy a single assembly than to deploy a set of SP's. This also ties in with #4.


6. Easier: You don't have to learn T-SQL to do data access, nor do you have to learn the data access API (e.g. ADO.NET) necessary for calling the SP's. This is related to #3 and #4.