Let's think about LINQ |
 |
By Mike Gunderloy, Contributor
10 Oct 2005 | SearchVB.com |
|
|
Now that the dust has settled from this year's PDC and we're all waiting for the VS2005 launch to happen, there's time to take a few minutes to reflect on what we learned. There were certainly a lot of interesting technologies trotted out on stage for developers to marvel at this year, with one of the most interesting being .NET Language Integrated Query - LINQ. You can download technology preview versions of LINQ that work with VB2005 (either the Beta 2 or RC builds) from the Visual Basic Future Versions page right now if you'd like to get your hands dirty.
I'd caution you, though, not to invest too much effort in learning and building things with this first public version. The PDC has always been Microsoft's venue for giving us early peeks of future technologies, and sometimes those technologies don't quite work out the way they'd hoped. If you'd gotten all excited from past PDCs, you might have put a lot of effort into writing code for WinFS -- or worse yet, HailStorm. While my gut feeling is that LINQ will in fact ship as part of the next major wave of .NET releases in 2008, I wouldn't want to bet on the current syntax remaining unchanged until then.
|
|
|
|
|
[T]here is no way of getting around the fact that LINQ in general, and DLinq and XLinq in particular, are going to require you to learn new stuff.
|
|
|
|
|
|
|
|
|
|
But it's not too early to start understanding the technology and thinking about its potential place in your solutions. In fact, it opens a window into the future of VB.
LINQ is designed as a general-purpose query facility that will be baked right into the .NET Framework. It allows traversal, projection, and filtering operations to be expressed in a declarative syntax in any .NET language, with benefits including compile-time syntax checking, static typing, and IntelliSense. LINQ queries can be applied to any data source that supports IEnumerable<T>. Microsoft is committed to supplying two particular implementations of LINQ for specific types of data: XLinq works over XML data, and DLinq works over relational data. The net effect is that you will be able to embed XPath/XQuery or SQL queries directly into your Visual Basic 9.0 code.
It sounds nifty, and it is, from a technical standpoint. Of course, there are already ways to embed SQL and XPath queries in your VB .NET code today, but none that will give you the declarative syntax and type checking benefits that LINQ promises. But you should also look beyond the shiny blinky lights and carefully consider a couple of pitfalls.
First, there is no way of getting around the fact that LINQ in general, and DLinq and XLinq in particular, are going to require you to learn new stuff. In addition to all the syntactic goo of XLinq and DLinq and LINQ themselves (and this is a not-inconsiderable amount of stuff), there are anonymous types and extension methods and relaxed delegates and dynamic interfaces and other goodies to bring into the mix.
But there's an action item here for today as well: If you're shaky on generics and delegates in VS2005, you're going to be completely lost when trying to come up to speed on the new stuff. There is simply no avoiding the fact that the VB language is becoming more and more complex, and using cutting-edge features like LINQ is going to require you to understand that complexity.
This doesn't mean you need to use every possible complex feature in every application you write (indeed, you should avoid some of the deeper features whenever you can, in the interest of writing maintainable code), but if you can't understand the whole language, you'll be left behind. So far it's been possible to get by in VB .NET based almost entirely on syntax remembered from VB 6.0, but those days are rapidly drawing to an end.
The other thing to realize is that the ability to embed queries, no matter how sexy the syntax or strong the typing, does not give you a free pass to forget everything you've learned about application architecture. I rather fear that the ease of embedding queries directly into code is going to cause some people to forget that those queries may be calling out to other components, leading to a troubling return of monolithic applications where the presentation tier is coupled directly to the database. If a three- or n-tier application makes sense before LINQ, it's still going to make sense after LINQ; there's no magic here that does away with the benefits of a clean separation of application tiers.
Obviously not every application needs such an architecture (it never has), but don't let the new toys blind you to the simple fact that good design will always matter. We've all got a few years now to figure out how LINQ and its derivatives fit in, and the winning developers will be those who integrate the new capabilities with their existing skills, not those who rush to re-implement everything according to the latest fashions while forgetting everything that they knew before.
Mike Gunderloy is an independent developer and author working in eastern Washington state. His recent books include Painless Project Management with FogBugz (Apress) and Coder to Developer (Sybex). You can read more of Mike's work at his Larkware Web site, or contact him at MikeG1@larkfarm.com.
|
|
|
|
