I'm using a pretty typical approach to learning this technology:
- Immersion in documentation. In this case, the local version of MSDN is up on my rightmost monitor. It's open to "Language-Integrated Query (LINQ)".
- Scratch projects for quick experimentation. Visual Studio is up on the main monitor. Only up to ConsoleApplication3 but this will go up as time goes on.
- Text document open for taking notes. UltraEdit is up on the leftmost monitor with "linq notes.txt" open.
The .NET framework in many ways represents a unification of basic semantic constructs that "should" be available to any modern programming language (technically the CLI does that but the point still stands). So it should come as no suprise that LINQ, a part of the .NET Framework, does a bit of unifying on its own.
I've seen a lot of data access abstractions: SQLJ, PERL-DBI, Jet, ADO, ADO.NET, SAX, DOM to name a few but LINQ takes it to a higher level of abstraction. Instead of providing a way to query these data structures in their "native" language (e.g., xpath for XML, SQL for RDBMS) it provides a single query notation/syntax for querying any data (or collection).
This is a brilliant unification. While I personally enjoy learning the nuances of SQL or XPath, most developers are loathe to have to learn a new query language and will often delay it, to the detriment of the product, for as long as possible.
I am usually very skeptical of anything that smacks of automatic object-relational mapping because a lot leaks through that boundary. At some level that's unavoidable but I'm hoping that LINQ to SQL at least, provides some way to "hint" about access paths to the underlying provider.