The evolution of LINQ and its influence on C # design

Simply put, LINQ is a series of language extensions that support querying data in a type-safe way, and it will be published in the next version of Visual Studio, code-named "Orcas." The data to be queried can be in the form of XML (LINQ to XML), Database (LINQ-enabled ado.net, including LINQ to SQL, LINQ to Dataset, and LINQ to Entities) and Objects (LINQ to Objects). The LINQ architecture is shown in Figure 1.

Figure 1 LINQ Architecture

Let's look at some code. In the upcoming "Orcas" version of C #, a LINQ query might look like the following:

　　var overdrawnQuery = from account in db.Accounts
　　where account.Balance < 0
　　select new { account.Name, account.Address };

When using foreach to traverse the results of this query, each returned element will contain the name and address of an account with a balance less than 0.

As you can see immediately from the example above, the syntax is similar to SQL. A few years ago, Anders Hejlsberg (C # 's chief architect) and Peter Golde had considered extending C # to better integrate data queries. Peter, the C # compiler development director, was studying the possibility of extending the C # compiler, especially the add-in that supports domain-specific language syntax, such as verifiable SQL. Anders, on the other hand, envisages deeper, more specific levels of integration. He was thinking of a set of "sequence operators" that could run on any collection that implements IEnumerable and on remote type queries that implement IQueryable. Ultimately, the idea of a sequence operator was most supported, and Anders submitted a document on the idea to Bill Gates's Thinkweek in early 2004. The feedback gives full recognition to this. In the early stages of design, the syntax for a simple query looks like this:

　　sequence locals = customers.where(ZipCode == 98112);

In this case, Sequence is the alias of the IEnumerable; The word where is a special operator that the compiler can understand. The implementation of the Where operator is a normal C # static method that accepts a delegate in the form of a predicate delegate, the bool Pred (T Item). The purpose of this idea is to have the editor have special knowledge about operators. This allows the compiler to correctly invoke the static method and create the code to associate the delegate with the expression.

Suppose the above example is the ideal query syntax for C #. In the absence of any language extensions, what does the query look like in C # 2.0?

IEnumerable locals = EnumerableExtensions.Where(customers,delegate(Customer c)
{
　return c.ZipCode == 98112;
});

This code is surprisingly verbose and, worse, requires very careful research to find the relevant filter (ZipCode = 98112). This is just a simple example; imagine how hard it would be to read code if you used several filters, projections, and so on. The reason for the verbosity is the syntax required by the anonymous method. In an ideal query, the expression does not make any demands in addition to the expression to be evaluated. The compiler then attempts to infer the context, for example, ZipCode actually refers to the ZipCode defined on the Customer. How to solve this problem? The ability to hard-code the knowledge of a particular operator into a language does not satisfy the language design team, so they begin to seek alternative syntax for anonymous methods. They require that the syntax be extremely concise, but without requiring more knowledge than the compiler currently required by the anonymous method. In the end, they invented lambda expressions.