It's hard to imagine a piece of software that never needs to query for data. When this happens, chances are that the data to query comes from a relational database. Like it or not, the old faithful Structured Query Language (SQL) invented in the early 70s at IBM is still our main source of inspiration when it comes to setting up a query against some data. Whenever we developers think of a query we automatically put it down as a SELECT FROM some sort of storage medium. In spite of the high demand for queries, programming languages never added query operators to their baggage; that is, until the newest Visual Basic .NET and C# compilers in the .NET Framework 3.5 shipped with the Language Integrated Query (LINQ) facilities. (The .NET Framework 3.5 is currently in Beta 2, but it's scheduled for release later this year).
Available in Visual Studio 2008, the new VB.NET and C# compilers make querying a first-class concept and supply ad hoc operators. It is interesting to point out that none of the core data classes in the .NET Framework (namely, system.data) has been touched to support the new query model. New classes and tools have been introduced in the .NET Framework, but they are insulated in new assemblies. Operators in the languages automatically bind to these low-level classes and make rich data queries a reality in the .NET Framework 3.5.
LINQ defines a set of query operators that allow code to filter, enumerate, and select data from a variety of data sources using the same syntax—to a large extent reminiscent of SQL. LINQ-enabled data sources currently include arrays, collections, ADO.NET DataSets, XML, and result sets obtained from relational databases. The model is extensible to the point that third-party vendors can create and sell their own LINQ engine to query inside of their own data model using the standard syntax and set of operators.
The general-purpose query engine of LINQ is specialized in a library specific of a given data source. So you have LINQ-to-SQL to query relational data, LINQ-to-XML to query XML documents, and so forth. All these engines belong to the .NET Framework and are backed up by language compilers. Because ASP.NET is just a development platform built on top of the .NET Framework, there's no reason why you can't query data in a Web context using any of the LINQ engines. The following code, therefore, is perfectly legal and works successfully as long as you run it from within an ASP.NET 3.5 project.
protected void Button1_Click(object sender, EventArgs e)
{
// Getting data
var data =
from c in context.Customers
where c.Country == "USA"
select c;
// Simple and direct binding
GridView1.DataSource = data;
GridView1.DataBind();
}
As you can see, the code is bound to the Click event of a Web button. It selects all the customers from the United States that can be located in the configured context (in the end, a connection string to a relational SQL Server database). Where are the new LINQ operators and syntax elements? The var element defines a piece of data whose type will be inferred at run time. Operators like from, where, and select—just like the similar SQL operators—define the returned result set of the query and its source.
Using LINQ syntax from within ASP.NET 3.5 page is definitely possible. Can we ask for more? In ASP.NET applications, you can use any flavors of LINQ in a variety of ways, mostly depending on your vision of the overall application's architecture. For example, you can use any LINQ syntax to query data directly in the UI layer of the pages. More likely, instead, you might want to use any LINQ in the Data Access Layer of a multi-tier system.
<asp:LinqDataSource ID="LinqDataSource1" runat="server"
ContextTypeName="NorthwindDataContext"
TableName="Customers"
Select="new (CustomerID, CompanyName, Country)"
Where="Country == @Country">
<whereparameters>
<asp:parameter Name="Country" Type="String" DefaultValue="USA" />
</whereparameters>
</asp:LinqDataSource>
Finally, if you love pages with a close-to-zero amount of code, you can use the new LinqDataSource control to specify LINQ commands and bind results to ASP.NET controls according to the popular data source model.
