Why do I need Stored Procedures when I have LINQ to SQL

Question

My understanding of Linq to Sql is it will take my Linq statement and convert it into an equivalent SQL statement.

So

var products = from p in db.Product         


        

Answer 1

Ah, the subject of many a debate.

Many would argue these days that technologies such as LINQ-to-SQL generate such good SQL these days that the performance advantages are marginal. Personally, I prefer SQL experts tuning SQL performance, not general coders, so I tend to disagree.

However, my main preference for stored procedures has less to do with performance and more to do with security and configuration management.

Much of my architectural work is on service-oriented solutions and by treating the database as a service, it is significantly aided by the use of stored procedures.

Principally, limiting access to the database through stored procedures creates a well-defined interface, limiting the attack surface area and increasing testability. Allowing applications direct access to the underlying data greatly increases the attack surface area, reducing security, and makes impact analysis extremely difficult.

Answer 2

Stored procedure support for LINQ to SQL was included partly for compatibility with existing systems. This allows developers to migrate from a sproc-based system to a fully LINQ-based system over time, sproc by sproc, rather than forcing developers to make a rush to convert an entire system all at once.

Answer 3

Sprocs are another tool in the box. You might use your fancy automatically-adjusting wrench for 90% of your tasks, but you can't use that shiny thing on stripped nuts. For that a good ol' monkey wrench is your best friend. Unless you break the bolt, in which case you're stuck with assembly.

Answer 4

I'm coming rather late to this thread. But depending on who you talk to, Linq to SQL is either dead, very dead, or at best a zombie.

In addition, no single tool suits every situation - you need to choose the right tool for the specific job in hand:

• Stored procs enable you to enforce complex business rules across multiple client applications.
• Stored procs can give you a great security layer.
• Stored procs can give you a great abstraction layer.
• Stored procs can give you better caching in some circumstances.

Answer 5

if that's all you ever did in sql, you didn't need sprocs before!

Answer 6

Personally, I don't care for LINQ. I like a separation of the data manipulation stuff and the code stuff. Additionally, the anonymous types that are generated from a LINQ statement cannot be passed-off to other layers of an n-tier application, so either the type needs to be concretely defined, or the LINQ call needs to be made in the UI. Gack!

Additionally, there are the security concerns (whatever user the LINQ code is calling into MS SQL Server under needs to have unfettered access to the data, so if that username/password are compromised, so is the data).

And lastly, LINQ to SQL only works for MS SQL Server (as it comes from MS).