Christian's Blog

As I'm a Microsoft MVP, I had the pleasure of seeing a demonstration of LINQ a few months ago. I seem to always be last through the gate on new stuff, mostly because I am so busy I guess. So, months later, I am finally taking the time to learn about LINQ. As it stands for Language INtegrated Query, I think it should be called LIQ, but that's another story.

Actually, the only reason I'm making time is that I agreed to do a user group presentation. I find that getting involved in things like this, or web articles, is a good way to motivate myself towards tasks that have no immediate cash reward, otherwise the paying work just takes over and I don't manage to make the time.

I've just been looking at a few articles around on LINQ, and the comments on some of them. Amongst all the 'wow that's amazing' type stuff, was a question : does this mean that my XML and database access is going to be faster ?

*sigh*

While I value C# for a lot of things, and one of those things is definately rapid development, I miss C++ for a lot of things, too. One thing I miss is a rich standard library, especially as it relates to containers and algorithms. I think that balance is being redressed, especially with LINQ. However, I've seen people on message boards say 'we're so lucky to be programming now, we don't have to understand pointers, and all that rubbish'. Well, I beg to differ. Years ago, I wrote a paint program, with alpha blended brushes, and all manner of effects. As I was coming to an end, I found GDI+ lurking in the PSDK, along with virtually no documentation. I wrote a series of Code Project articles on GDI+ as a result, for once I was ahead of the curve. And I rewrote all my tools to use GDI+. I'm of the school that says every programmer should, for example, write a linked list class, but never, ever use it. You need to know how this stuff works, but you should use the stuff that your language provides, and assume it's been put under closer scrutiny than your class, and survived. So, I am very glad that I learned how to write all of those filters and tools using GDI only, although nowadays, given the option, I'd rather use GDI+, the point is that I have a pretty good idea what I'm asking GDI+ to do, and what it's likely to cost me.

So, back to my friend who thinks that LINQ will make his database faster. I've not looked into DLINQ in any depth yet, but how is it even possible that having an extra layer that dynamically generates SQL is going to make things FASTER ? I'd be praying for no change in speed, personally, especially as we're now sending dymanically generated SQL to the database, whereas any DB code I write is calling stored procedures, which SQL Server will precompile, and which results in less network traffic for the request.

Don't get me wrong, I think LINQ is an awesome idea, but like a lot of ideas ( managed code in SQL Server springs to mind ), it's a tool that no doubt can be abused, as well as being really useful if done with care. I will be doing some testing of DLINQ to see how it fares, speed wise, and to better understand how using it will affect my database security ( I like to run as a user who can only call stored procs, which greatly limits the harm anyone can do ). No doubt, when I find time to do this, I will make the results known here. For the time being I'm focusing on the stuff where I expect it most to shine, that is, in creating a framework that allows me to write reusable algorithms for filtering and processing collections and XML.