Hi, David,

Sorry it's taken me so long to get back to you. Your message was interesting.

There was a very interesting discussion about SP's this morning in a LINQ to SQL session I attended (from C# point of view). Luca Bolognese (a C# PM) was back-pedalling quite a lot from the old Microsoft guidance about putting everything into SPs. One of the MVPs challenged him about why MS told everyone 5 years ago that SPs were the best choice and now they're saying that LINQ-generated SQL is a good thing.

Shame on you - what happens at the summit needs to stay at the summit. ;)

Anyway, from what I understand, not very surprising, as many seem to bean in and out of the LINQ pot. ;)

His points included the fact that way back when the SP guidance was being stated by MS, it was very much for SQL Server optimization purposes, but now dynamic parameterized queries can be better optimized so the perf differences are not much of a factor.

If you mean auto-parameterization of queries and parameter sniffing, yes, there's been progress on that front. I still argue that it depends on the query.

That being said, there will be some support for SPs in LINQ to SQL (particularly for Insert/Update/Delete), but the exact shape and limitations are yet to be defined. Handling dynamically generated Selects with where and orderby clauses will be more problematic to map to SProcs. I told him, just give us the hooks at the appropriate places under the covers so we can trap the process and point to whatever SPs we deem appropriate, and don't try to figure out what to map to in every case.

We may get that - but doesn't that defeat the purpose of the toolset?

We also talked a LOT about the need to base LINQ to SQL on a provider model, so that other implementations can be developed and plugged into it-- it will support just SQL Server 2000 and SQL Server 2005 at first. We may or may not get a chance to tie in custom providers at a lower level without having to write a complete LINQ to WHATEVER piece, but they hope to have some clarity on that soon.

I think that's more or less what they are doing.


Anyway, I got a good chuckle out of the discussion about SPs and thought of you. :-)

What surprises me is that so many posts on LINQ are database related (LINQ to SQL), as opposed to LINQ queries of in-memory collections (LINQ to Objects), or XML questions (LINQ to XML). LINQ adds so much more to in-memory collection queries and XML queries or generation than it does to database queries. Sure, performing LINQ queries on a SQL Server database is nice, but I already have a SQL-like method of getting data from the database. It's called SQL. <s>

To me, this is far cooler than the LINQ to SQL stuff.

Kevin