No, Zelda is not back. LINQ stands for
Language Integrated Query.
It's a set of query operators that can be called in any .NET language to query, project,
and filter data from any type of data source. Types include arrays, databases, IEnumerables,
Lists, etc, including third party Data Sources. It's pretty neat.
Essentially LINQ pulls the data into data objects, which can then be used as you would
use a Business Object. The data object is predefined by a LINQ Provider. Out of the
box you have
LINQ to SQL, LINQ to XML, and LINQ to Objects for providers. Once
you define the data object based on provider you can start querying data:
Within the
foreach loop the 'Customers' class is a data class that was defined
based on a LINQ to SQL Provider. In this case, the database was Northwind.
Syntactically LINQ is very much like the SQL language, mainly because they both work
on the same principle. Query (possible) large amounts of data and act on it appropriately.
SQL is designed to work with large datasets. Most other languages work iteratively.
So SQL was a good language choice to mimic.
However, there is a small problem that I see with LINQ. If I'm doing all the querying
at the DAL layer instead of using things like Stored Procedures within the database,
and I need to modify a query for performance concerns, that means the DAL has to be
recompiled and redistributed to each application out in the field. That could be 10,000
different instances. Wouldn't it make more sense to keep the query within a Stored
Procedure? Just a thought...
