Adding LINQ to Visual Studio: Does this change everything?

For over a decade, database developers have been begging for a kind of bridge that enables procedural language programs to access relational databases relationally. Now that bridge is coming. But are developers ready for LINQ? We asked Microsoft's Visual Studio general manager, Jason Zander.

LOS ANGELES (BetaNews) - The first genuine effort to create a uniform set of database drivers for Windows came in 1988, when an independent firm started as a consultancy called Pioneer Software launched a product and an idea called Q+E -- a tool for linking its own database editor, and later Microsoft applications such as Excel, to any number of existing databases through stand-alone providers. It was indeed a revolutionary concept, and it gave birth to a never-equaled database connectivity standard called ODBC.

Sixteen years ago, I wrote a book that first revealed the existence of that project and Pioneer's involvement with it. The successor to that company, DataDirect Technologies, later pioneered the Java equivalent called JDBC, and even today produces ODBC data providers using Pioneer's original concept.

Connecting a procedural language program (such as C# or Visual Basic) to an ODBC database required a convoluted, though somewhat stable, protocol that forced developers to jump through hoops. Among them, the developer had to craft something called a connection string that's like the header of an IP packet, containing identification information in a discrete sequence. Six years later, I published another book which, among other things, explained that process. In it, I wrote:

With the release of Visual Studio 2008 (which actually took place on an official level last November, but which was celebrated last week), the replacement process for ODBC has begun. Replacing it is a vastly improved and startlingly different way to contact data, called Language Integrated Query (LINQ). Rather than create connection strings, assign them to variables, and pass them off as arguments to device drivers, LINQ queries are literally embedded in source code, becoming one with the program for any language (theoretically) that supports the .NET Framework.

Last Wednesday, we discussed the implications of LINQ face-to-face with Microsoft's general manager for Visual Studio development, Jason Zander.

SCOTT FULTON, BetaNews: I've heard LINQ described by many people as being able to make certain aspects of managing data within a static application easier. But for everybody I've tried to explain it to, they've said, "That's so different from anything I've ever done before." It's almost as if we've been used to driving two-dimensionally with our automobiles, and suddenly we have "up." "Up" is now available, this will make your life easier. And yes, it does make it easier for me to go "up," but is that easier?

Microsoft General Manager for Visual Studio Developer Division, Jason Zander

JASON ZANDER: Yea, for you to have a broader view of everything in front of you.

Here's the thing: You're not going to have to stop using the concepts that you've already got. That much is clear. To me, what it really comes down to is a productivity thing. One of the first teams I was in at Microsoft was ODBC. I did the original database drivers, and I actually worked on Distributed SQL at IBM before that...The problem that I have with that type of code is, you're going to have to write a bunch of boilerplate, right? I've got to go get the connection, I got to assign a string to it, I've got to understand T-SQL, escape clauses...how do I sort all this out?

SCOTT FULTON: You did this!

JASON ZANDER: I did this, in a prior life. You can blame me.

So the thing I really like about this [LINQ], though, is it uses concepts that are intuitive -- and I believe that SQL itself, the grammar, is intuitive. FROM this source, WHERE these things are true, grab this piece of data, put it together this way, filter it, sort it. What could be more intuitive? And I don't have to go off and program it against a bunch of class libraries. We made that easy, but hey, it's so much easier to put one keyword in front and have that happen. So now I can take all this boilerplate code that you used to have to write, and [pinches fingers together] it's about this big. So the productivity, I think, makes it really fast.

The other thing that I'd point out is, LINQ itself is not just for SQL. You can manipulate objects for XML and a whole bunch of other things, and because of the way those other things compose together, I can combine them. I can make, for example, a Web service call, [then] pull back the XML and use the link to XML Provider to actually shred that apart. I can now do a JOIN -- that's a new keyword -- to link to SQL on a database, and I can say, "Hey, Web service call, give me all my customers in Alabama, then JOIN it to my database over here, let's go find all of the usage data for customers in Alabama over here, pull the data back," and poof, it's all together.

We're actually working also on a link to Outlook Provider, which we haven't released yet but we've been playing with it. So imagine being able to say, FROM message IN Inbox WHERE from = "Steve B." AND subject = "LA Launch". I just shredded my whole Inbox, and poof, here's the result. That's really powerful. And how else would you get that to work in another environment without writing a SQL driver, or something like that?

Next: Merging JOIN and UNION into a procedural language...