As you might expect, yesterday's announcement of the .NET Integrated Query Framework (LINQ) certainly has my attention. Its pretty hard to put down more than a stream of thought about this right now, but here's some of the implications as I see them.
- Its cool because, as a developer, I'll be able to express my queries in-line as part of the program
- That could be less than cool if I'm blindly dragging a lot data from the server to my application that I don't need and don't use but don't know that I'm doing that because my code is so "mindlessly simply."
- LINQ does mean you can spend less time learning the depths and eccentricities of T-SQL, XQuery and XPath
- LINQ doesn't mean you shouldn't you shouldn't spend time learning and really understanding T-SQL, XQuery and XPath. Why? See the next two points
- LINQ certainly does simplify writing code, but it doesn't help you design the application any better. There's nothing in LINQ that helps you decide, for example, if a dynamic SQL query is more appropriate than using a stored procedure. For that, you've got understand the SQL Server internals. As these things are expressed today in terms of the native language of the platform which is T-SQL. Same for XQuery in the sense that if you don't understand namespaces, XPath and schema -- you're going to struggle to getting optimal performance and usability of out of LINQ -- or anything else for that matter.
- LINQ is a Microsoft-specific generic query technology where as XQuery is a vendor and platform neutral query language over XML. What's the difference? If you're Developer working in a Microsoft-only world, you'll probably come to prefer XLINQ over XQuery for reasonably local data query for many reasons. If you're a developer who needs to work with many different technologies that can express their data and information in XML, XQuery is probably is probably going to be your choice since its an otherwise well-support standard.
- Microsoft Neither XQuery or T-SQL is depreciated or going away any time soon.
- However, LINQ is the first step towards an obvious end: A single query description and processing framework integrated at a very low level. Any query language, be it T-SQL, XQuery, XPath, XSLT, OPath, C#, VB.NET -- whatever -- can be compiled down to into a common query plan format and feed into a common query processing environment. The query processing environment could then sit on top of any data store, from Relational like SQL Server and JET, File stream and metadata like WinFS, Document storage or whatever.
So what the bottom line? LINQ is cool and will no doubt simplify the code writing effort. But that's not the big bang here. The big bang is that its the start of creating an entirely new way of distributing data, information and query over many network nodes. It gives us a way to write such queries our "native language" but have the executable over essentially anything anywhere.
That's truly powerful, but it shifts what you do have to know from "know the language" to "know the patterns." We've seen this before. Its what .NET for application development at a general level. With .NET, it doesn't matter much which language you use, but its does matter that you design the application right and that's where patterns apply.