If you are having difficulty with the whole idea of LINQ to XML, I would suggest stepping back a bit and just looking at linq as a whole. I believe linq is very worth the effort and will pay you back many times - especially when we move into the multi-user world.
I would suggest that you forget the XML part for a moment and just think about what linq does - after you get what linq is about, then this will make the specialized material for XML simpler. It helps me think about this with these two considerations:
- It expresses standard “operators” (extension methods) on everything that implements the IEnumerable <T> interface. In other words, linq is just a method call. Some of the methods accept (Func) in the code, some (First ()) do not.
- this allows you to care less about how these operators give you the result, and most of all announces your intention .
It’s not easy for us to require that language people let go of the minute (more) specification of how to get the result. That linq basically gives us a way to declare , we want to get the result without specifying exactly how to get it. That's why, IMO, linq is so important to learn, because it is this “decoupling” of intent from the exact “how” that is really the cool part of linq. This basically translates the concept of functional language into the poor old imperative C #.
A useful tutorial for LINQ is to write imperative C # code that will do the same . Do this several times, and suddenly you will see the template that linq does for you. So, for example, consider the declaration of "linq-to-object".
string[] names= new string[] { "kevin", "tristan", jen" }; var result = names.where(n => n.length() > 3);
an analog in C # for a linq request would be:
List<string> list = new List<string>(); foreach(string n in names) { if (n.length > 3) list.add(n); }
I think that in this example it’s pretty easy to see how linq does the same thing as foreach (actually it’s very close to reality) - but you don’t have all the fluff that is just a goo compiler. There are less problems and more intentions in the linq version. Another way to express it: linq makes boring boilerplate stuff implicit for you , letting your code just show the interesting part.
In a functional expression, the where () method is a higher-order function . This means that it is a function that itself takes or returns a function. Where () takes lambda - an interesting part of the loop . Lambda is an anonymous function in C #, so Where () takes a function, so it is of a higher order . I mention this because this concept is so strong and the key to understanding linq and gives an idea of how linq actually represents a completely new programming model (functional programming), anchored in C #. Getting this "higher order" is very useful for understanding linq.
Working with a direct list <T> I think that queries like the one above are the best way to wrap linq around you. Afer you feel comfortable with straignt L-2-O requests and then look at the XML stuff again - I think you will find that they will make more sense.
With the Reactive Framework released in .NET 4.0, we will see that linq expands not only for pull requests, but also for push scripts. Ie: the collection will generate code when it changes. I am convinced that the concepts of functional programming (of which linq is the C # tunnel) are the most likely ways to get bread and butter that we will handle concurrency and parallel problems, so it is very important to study them, and not just make our code shorter .