Dave,

Sounds like I missed a good discussion ... the LINQ to SQL session I attended barely touched on this issue. I remember arguing with Luca at the Summit in 2005 about this very thing. This and typed DataSets. At the time, he didn't quite "get" what it was I was trying to tell him. It sounds like there's support for DataSets now, but no one seems to want to talk about it. I'll have to do my own digging I guess.

I'm still not 100% convinced that LINQ to SQL is going to improve much in the way of Data Access ... you still have to figure out the changes on your own unless you've made the data changes in the same instance of your Data Access class ... not a likely scenario in a distrubuted architecture. Unless I missed something totally (which is possible I suppose <g>).

~~Bonnie




>>...I still sincerely believe that SPs are the starting point - but if this capability indeed makes it into LINQ, it will certainly ease the transition for people in need of auto-spanning.
>
>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.
>
>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.
>
>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 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.
>
>Anyway, I got a good chuckle out of the discussion about SPs and thought of you. :-)