Start understanding LINQ from Query expressions

Learning and using C # has been 2 months, in this two months of study, deep experience, C # This language is really not suitable for programming beginners to learn, because it is a lot of other languages, not only object-oriented, but also including functional language of many features, leading to it into the characteristics of the Big Bang language. Many aspects of it come out alone, it has to be a book of size, and not necessarily let people suddenly understand.

Linq,language Integrated Query, language integration queries, is a very important part of its enhancements, throughout the development of C #.

Start with the basic query expression.

Before we talk about query expressions, we have to understand that the query expression is not just for the database, it is for all data sources, because LINQ is intended to provide a uniform way of access for all data sources. Because the most recent project is using LINQ to SQL, only LINQ to SQL is spoken here.

The query expression is very much like an SQL statement, but it is written in the opposite way:

var articles = from article in db. Articles
              where a.name = = "JIM"
              select article;

We must understand that the query expression returns the result of a sequence, even if the sequence has only one element.

Because the query expression returns a sequence, it makes its behavior very interesting. The basic feature of a sequence is to take only one element at a time, so that each transformation processes one data and the query expression begins only when the first element of the result sequence is accessed. Like the data stream above: The Select transformation invokes the where transformation for the element when the first element in the sequence it returns is accessed, and the where transformation returns the first element in the list of data, checking whether the predicate (a.name = "JIM") matches, The element is then returned to the select.

This is the deferred execution of the query expression, which did not process any data when it was created, but only the delegate that generated the query in memory. This is very efficient and flexible, but not all situations are appropriate, like reverse this kind of operation, it is necessary to access the entire data source. So, we typically use deferred execution in an operation that returns another sequence, and use instant execution if you return a single value.

Using a query expression, first is the data source that declares the data series:

From article in Db. Articles

The WHERE clause is used for filtering. It enters the predicate for each element in the data flow, and only elements that return true can appear in the result sequence. We can use multiple where clauses, and only elements that satisfy all predicates can enter the result sequence.

The compiler converts a WHERE clause to a where method call with a lambda expression, like this:

Where (article => article). Name = = "JIM")

So we can also use the lambda expression directly, which is also to return a sequence:

var articles = db. Articles.where (Article => article)

Using lambda expressions can dramatically increase the simplicity of our code, which is one of the reasons why it has been introduced into C #.

The SELECT clause is the projection, I believe that the students who have studied the database must be very familiar. It also has a corresponding method call, and it should be said that almost all LINQ to SQL operations have corresponding method calls (because the compiler is saying they are converted to method calls), so the next step is to stop the method invocation form.

As I mentioned earlier, the compiler converts a query expression to a method call to a normal C # code, and in the case of select, it is not converted to Enumerable.select or LIST<T> as we expected. Select, it simply converts the code and then looks for the appropriate method. The parameter of the method is either a delegate type or a expression<t>. Why is the parameter in the converted method A lambda expression? Because a lambda expression can be converted to a delegate instance or an expression tree, you can use a lambda expression to correspond to all situations. This conversion does not depend on a particular type, but only on the compile-time form of the method name and parameter, the so-called dynamic type (Duck Typing).

Because of this, we can implement our own LINQ provider, but we don't need to do that unless there really is a special need.

Let's look at two of the most important components of a query expression: range variables and projection expressions.

From article in Db. Articles

Where article is the range variable, and:

Select article

The projection expression uses the range variable. When the compiler converts, the left side of the lambda expression, the parameter name is the range variable, and the right comes from the projection expression, so we must not write this:

From article in Db. Articles
Select person

From the above, the scope variable should be an implicit type, and the compiler will infer its specific type. Of course, we can also use an explicit type of range variable, like the following:

From Article Article in db. Articles
Select article

of which, DB. Articles is a list<article>.

This is because we want to query in a strongly typed container. The guarantee that such a mechanism can operate stems from one method: Cast (). Cast () forces the type to be converted to the target type, and an error occurs if it cannot be converted.

The expression above will be converted to the following code:

List. Cast<article> (). Select (article => article);

Why do we need to explicitly declare a range variable? Because the Select method is simply a ienumerable<t> extension method, not a IEnumerable, we must explicitly declare the type of the range variable to invoke the Select method.