At the recent Orlando Code Camp I had the opportunity to spend a good bit of time discussing LINQ to SQL with Jim Wooley, author of Linq In Action. It was really an interesting conversation. Clearly Jim likes LINQ and sees some opportunities there for developers. As we discussed it more a couple interesting ideas came up. One was that he suggested using table valued functions (essentially parameterized views) as a way to avoid granting table access for LINQ use. Interesting, but not my favorite technique because; one, functions don't always thrill me with performance, and two, it's a hack! It's actually a useable idea, but I think it definitely steps us in a direction I'm not sure I agree with.

I've taken it for granted that everyone understood that allowing full table access is a really bad idea from a security perspective. Should we rethink that? If I can call a proc and pass an employeeid, nothing stops me from writing a loop and calling the proc a thousand times to achieve the same results, right? It's just not as easy and I think that's part of the value. DBA's, if you really step back from this issue and look at it, if - big IF - they could save 10% coding time moving to LINQ is it worth the risk to the business, and is it real risk or just our perception? 

Another part of the conversation was me wanting to know why developers find LINQ to SQL so seductive and his answer (and I think he's right), is that developers see data access code as dull and they just don't want to do it. Strikes me as a little lazy! I wish I could only work on the cool stuff! Combine that with a lot of the friction that has developed between developer/DBA over the years and they are all to ready to do an end run whether it's a good idea or not. I've got to work on this some more, but I think that attitude/perception combined with a lack of helper tools has lead us to this place.

My final thought/worry is that MS itself is going to relegate stored procs to the backseat and the developers will follow. The optimistic thought is that they see something in it that we don't yet, the pessimistic thought is that they've given up on developers and data access and are trying to seduce them into tools that at least do a mininum level of decent data access. 

Anyway, if you need a LINQ book buy Jim's, he's a smart guy and a nice guy, and was kind enough to help me explore some thoughts on Linq - even if we didn't always agree!