Sunday, February 22, 2009

LINQ

Hey guys!

I have to say, I'm a little disappointed.

Having played about with LINQ briefly I thought it was a really good idea, especially having to not need to work out complex joins and the like. I thought that is was a really good idea.

If you push the technology to the point where you threaten to use it in an enterprise solution, I found that whilst you don't have to work out the SQL side of things, or the joins, really you do. Some unexpected side effects within LINQ, such as not being able to mix and match LINQ to SQL and LINQ to Objects, so running in to problms with code re-use means that the technology requires a much more in depth knowledge than one might be required to learn to use stored procedures.

I also found that performance in the simple scenario was great, but again, if pushed hard the technology was not great performance wise. That meant that using LINQ meant mixing and matching the LINQ language with stored procedures, which in my mind at least undoes it's purpose - language independence.

One other thing - if you want to keep a traditional data layer, without any technology bleed, and make LINQ work properly, well basically, you can't. It seems that each layer having its own model, whilst a good idea in theory isn't something that you'd really want to do with LINQ. I might be being unfair to technology, but from what I could see, the LINQ objects needed to be used to keep state information, which makes the technology basically a desktop technology, much like the dataset in a lot of ways, but with a fancy language to sit in front of it.

I'm going to keep going with the technology, as I like the concept, to see if I can find a way around it, to make use of it in such a way that it is actually useful, but at this point, it simply seems like a fancy language, with some very cool technology, but no real follow through. Really, that's a shame.

No comments: