Language Integrated Query | |
Designer: | Microsoft Corporation |
Developer: | Microsoft Corporation |
Turing-Complete: | No |
Typing: | Strongly typed |
Implementations: | .NET languages (C#, F#, VB.NET) |
Influenced By: | SQL, Haskell |
Website: | https://learn.microsoft.com/en-us/dotnet/standard/linq/ |
Language Integrated Query (LINQ, pronounced "link") is a Microsoft .NET Framework component that adds native data querying capabilities to .NET languages, originally released as a major part of .NET Framework 3.5 in 2007.
LINQ extends the language by the addition of query expressions, which are akin to SQL statements, and can be used to conveniently extract and process data from arrays, enumerable classes, XML documents, relational databases, and third-party data sources. Other uses, which utilize query expressions as a general framework for readably composing arbitrary computations, include the construction of event handlers[1] or monadic parsers.[2] It also defines a set of method names (called standard query operators, or standard sequence operators), along with translation rules used by the compiler to translate query syntax expressions into expressions using fluent-style (called method syntax by Microsoft) with these method names, lambda expressions and anonymous types.
Ports of LINQ exist for PHP (PHPLinq), JavaScript (linq.js), TypeScript (linq.ts), and ActionScript (ActionLinq), although none are strictly equivalent to LINQ in the .NET inspired languages C#, F# and VB.NET (where it is a part of the language, not an external library, and where it often addresses a wider range of needs).
In what follows, the descriptions of the operators are based on the application of working with collections. Many of the operators take other functions as arguments. These functions may be supplied in the form of a named method or anonymous function.
The set of query operators defined by LINQ is exposed to the user as the Standard Query Operator (SQO) API. The query operators supported by the API are:[3]
These operators optionally take a function that retrieves a certain numeric value from each element in the collection and uses it to find the sum, minimum, maximum or average values of all the elements in the collection, respectively. Overloaded versions take no function and act as if the identity is given as the lambda.
IGrouping<Key, Values>
objects, for each distinct key value. The IGrouping
objects can then be used to enumerate all the objects for a particular key value.
The Standard Query Operator API also specifies certain operators that convert a collection into another type:[3]
IEnumerable<T>
.[4]IQueryable<T>
.T[]
from the collection.List<T>
from the collection.Dictionary<K, T>
from the collection, indexed by the key K. A user supplied projection function extracts a key from each element.Lookup<K, T>
from the collection, indexed by the key K. A user supplied projection function extracts a key from each element.IEnumerable
collection to one of IEnumerable<T>
by casting each element to type T
. Alternately converts a generic IEnumerable<T>
to another generic IEnumerable<R>
by casting each element from type T
to type R
. Throws an exception in any element cannot be cast to the indicated type.IEnumerable
collection to one of IEnumerable<T>
. Alternately converts a generic IEnumerable<T>
to another generic IEnumerable<R>
by attempting to cast each element from type T
to type R
. In both cases, only the subset of elements successfully cast to the target type are included. No exceptions are thrown.While LINQ is primarily implemented as a library for .NET Framework 3.5, it also defines optional language extensions that make queries a first-class language construct and provide syntactic sugar for writing queries. These language extensions have initially been implemented in C# 3.0,[5] VB 9.0, F#[6] and Oxygene, with other languages like Nemerle having announced preliminary support. The language extensions include:[7]
var
keyword. In VB9.0, the Dim
keyword without type declaration accomplishes the same. Such objects are still strongly typed; for these objects the compiler infers the types of variables via type inference, which allows the results of the queries to be specified and defined without declaring the type of the intermediate variables.Object initializers allow an object to be created and initialized in a single scope, as required for Select and Join operators.
Lambda expressions allow predicates and other projection functions to be written inline with a concise syntax, and support full lexical closure. They are captured into parameters as delegates or expression trees depending on the Query Provider.
For example, in the query to select all the objects in a collection with SomeProperty
less than 10,
foreach (var result in results)
the types of variables result, c and results all are inferred by the compiler in accordance to the signatures of the methods eventually used. The basis for choosing the methods is formed by the query expression-free translation result
results.ForEach(x =>)
The C#3.0 specification defines a Query Expression Pattern along with translation rules from a LINQ expression to an expression in a subset of C# 3.0 without LINQ expressions. The translation thus defined is actually un-typed, which, in addition to lambda expressions being interpretable as either delegates or expression trees, allows for a great degree of flexibility for libraries wishing to expose parts of their interface as LINQ expression clauses. For example, LINQ to Objects works onIEnumerable<T>
s and with delegates, whereas LINQ to SQL makes use of the expression trees.
The expression trees are at the core of the LINQ extensibility mechanism, by which LINQ can be adapted for many data sources. The expression trees are handed over to LINQ Providers, which are data source-specific implementations that adapt the LINQ queries to be used with the data source. If they choose so, the LINQ Providers analyze the expression trees contained in a query in order to generate essential pieces needed for the execution of a query. This can be SQL fragments or any other completely different representation of code as further manipulatable data.LINQ comes with LINQ Providers for in-memory object collections, Microsoft SQL Server databases, ADO.NET datasets and XML documents. These different providers define the different flavors of LINQ:
The LINQ to Objects provider is used for in-memory collections, using the local query execution engine of LINQ. The code generated by this provider refers to the implementation of the standard query operators as defined on the Sequence
pattern and allows IEnumerable<T>
collections to be queried locally. Current implementation of LINQ to Objects perform interface implementation checks to allow for fast membership tests, counts, and indexed lookup operations when they are supported by the runtime type of the IEnumerable.[9] [10] [11]
The LINQ to XML provider converts an XML document to a collection of XElement
objects, which are then queried against using the local execution engine that is provided as a part of the implementation of the standard query operator.[12]
The LINQ to SQL provider allows LINQ to be used to query Microsoft SQL Server databases, including SQL Server Compact databases. Since SQL Server data may reside on a remote server, and because SQL Server has its own query engine, LINQ to SQL does not use the query engine of LINQ. Instead, it converts a LINQ query to a SQL query that is then sent to SQL Server for processing.[13] However, since SQL Server stores the data as relational data and LINQ works with data encapsulated in objects, the two representations must be mapped to one another. For this reason, LINQ to SQL also defines a mapping framework. The mapping is done by defining classes that correspond to the tables in the database, and containing all or a subset of the columns in the table as data members.[14] The correspondence, along with other relational model attributes such as primary keys, are specified using LINQ to SQL-defined attributes. For example,
This class definition maps to a table named Customers
and the two data members correspond to two columns. The classes must be defined before LINQ to SQL can be used. Visual Studio 2008 includes a mapping designer that can be used to create the mapping between the data schemas in the object as well as the relational domain. It can automatically create the corresponding classes from a database schema, as well as allow manual editing to create a different view by using only a subset of the tables or columns in a table.[14]
The mapping is implemented by the DataContext
that takes a connection string to the server, and can be used to generate a Table<T>
where T is the type to which the database table will be mapped. The Table<T>
encapsulates the data in the table, and implements the IQueryable<T>
interface, so that the expression tree is created, which the LINQ to SQL provider handles. It converts the query into T-SQL and retrieves the result set from the database server. Since the processing happens at the database server, local methods, which are not defined as a part of the lambda expressions representing the predicates, cannot be used. However, it can use the stored procedures on the server. Any changes to the result set are tracked and can be submitted back to the database server.[14]
Since the LINQ to SQL provider (above) works only with Microsoft SQL Server databases, in order to support any generic database, LINQ also includes the LINQ to DataSets. It uses ADO.NET to handle the communication with the database. Once the data is in ADO.NET Datasets, LINQ to DataSets execute queries against these datasets.[15]
Non-professional users may struggle with subtleties in the LINQ to Objects features and syntax. Naive LINQ implementation patterns can lead to a catastrophic degradation of performance.[16] [17]
LINQ to XML and LINQ to SQL performance compared to ADO.NET depends on the use case.[18] [19]
Version 4 of the .NET framework includes PLINQ, or Parallel LINQ, a parallel execution engine for LINQ queries. It defines the ParallelQuery<T>
class. Any implementation of the IEnumerable<T>
interface can take advantage of the PLINQ engine by calling the AsParallel<T>(this IEnumerable<T>)
extension method defined by the ParallelEnumerable class in the System.Linq namespace of the .NET framework.[20] The PLINQ engine can execute parts of a query concurrently on multiple threads, providing faster results.[21]
Many of the concepts that LINQ introduced were originally tested in Microsoft's Cω research project, formerly known by the codenames X# (X Sharp) and Xen. It was renamed Cω after Polyphonic C#, another research language based on the join calculus, was integrated into it.
Cω attempts to make datastores (such as databases and XML documents) accessible with the same ease and type safety as traditional types like strings and arrays. Many of these ideas were inherited from an earlier incubation project within the WebData XML team called X# and Xen. Cω also includes new constructs to support concurrent programming; these features were largely derived from the earlier Polyphonic C# project.[22]
First available in 2004 as a compiler preview, Cω's features were subsequently used by Microsoft in the creation of the LINQ features released in 2007 in .NET version 3.5[23] The concurrency constructs have also been released in a slightly modified form as a library, named Joins Concurrency Library, for C# and other .NET languages by Microsoft Research.[24]