. NET in-depth parsing of LINQ Frameworks (vi: LINQ execution Expressions)

Read the catalogue:

• 1.LINQ Execution Expression

Before reading this article I assume that you already have some of the principles I have previously analyzed, because this chapter is based on a series of previous knowledge points, in order to ensure that your reading smoothly suggest that you read the first few of my LINQ series or you already have a more in-depth knowledge of the LINQ theory system, Prevent your valuable time from being wasted.

So far we have made it clear how LINQ works, from its pre-conception to what it really does for us, but it seems that the problem is not as simple as we think, and that the problem is always in our use, especially with the use of new technologies, and of course there are problems to make progress.

One: LINQ execution expressions

In the process of studying LINQ, there are many technical articles and technical books, and there is no doubt that the invocation portal of LINQ to Provider is to parse a lambda expression into an expression<t> expression object, unlike LINQ to object, Linq to object is a delegate that parses a lambda directly into a generic Func type, but many of us, including myself, have overlooked a great deal of detail, which is that provider will execute the expression<t> internally, Not as we understand it, the expression expression<t> object is fully parsed into equivalent SQL, meaning that expression<t> is not as simple as we see it, it has a dual context logic inside it.

We all use LINQ directly as the query interface, and VS is responsible for parsing the LINQ syntax and translating it into corresponding extension method calls at the time of the final compilation. It is important that we ignore an important aspect of the fact that the LINQ expression is executed when VS is parsing the translation for LINQ. I used to think that vs was only responsible for translating the LINQ expressions into equivalent extension method calls, and then found that vs was able to stitch the where sentence in case we couldn't determine the object's condition in the early stages, allowing us to write a LINQ statement with a logical judgment expression in it, This function is very convenient for us to make a multi-conditional combination query, without having to make multiple judgments of if and else, just let it be judged naturally in the first expression in LINQ. The pursuit of elegant code of the comrades do not want to have a LINQ query and a chain query method with two query methods, if LINQ can satisfy most of the query function that the most perfect;

To illustrate that LINQ is executed by vs at compile time, we use the LINQPad tool to see it;

LINQ query expression: From truck in tb_cx_trucks where 1==1 select truck

LINQ-Equivalent Chaining method: tb_cx_trucks.where (truck = True)

Figure 1:

If there is no justification for parsing directly into the lambda format (truck) =>1==1, then let the LINQ to provider provider handle the pair, perhaps thinking that there is no real meaning, anyway, is an identical expression so parse it into this. We're looking at a different way of writing.

LINQ query expression: From truck in Tb_cx_trucks where string. IsNullOrEmpty ("1111") Select truck

LINQ-Equivalent Chaining method: tb_cx_trucks.where (truck = string.isnullorempty ("1111"))

Figure 2:

It can be concluded that LINQ statements are two actions that will be executed and parsed, and that LINQ can be shipped with some execution logic instead of the final SQL execution logic when it has not yet entered the provider.

The processing of expressions can be divided into constant expressions and dynamic variable expressions, and constant expressions can evaluate whether the expression is true or false at vs compile time. Dynamic variable expressions need to be computed at the end of the expression parsing, in other words, the provider provider in LINQ to provider is an expression executor with a high IQ, and not just a custom logic code that parses the expression in the middle of an equivalent parsing of an expression.

For example, we all have the experience of stitching query condition, there are N query condition fields on the interface, we need to make a dynamic splicing into the LINQ statement according to whether the user has filled out which field. In general, we will make the if judgment, because we all feel that the conditional expression behind the where is parsed directly into the corresponding logic of the SQL statement, so as long as the concatenation is parsed into the SQL WHERE clause. Since LINQ cannot be disassembled for assembly, it must be written once before it can be compiled. So we are using the query extension method for data query, such a dilemma so that we can not see the elegance of LINQ, but has not been used.

By observing the SQL statement parsed by the LINQPad tool, it is found that the LINQ query expression will be executed within the provider, parsing two processes, the same as the process of VS, can execute first, then parse, and parse is based on the previous execution. Let's look at a simpler SQL and chained approach to LINQ parsing;

LINQ query expression: From truck in tb_cx_trucks where 1==1 | | Truck. License_number. LENGTH<10 Select Truck

LINQ-Equivalent Chaining method: tb_cx_trucks.where (truck = (True | | | (Truck. License_number. Length < 10)))

Figure 3:

In contrast to the chain method, it is clear that vs first executes the 1==1 expression and returns true as part of the entire expression behind the concatenation of the Where Chain method, so first perform a further two procedures. Then we analyze the last SQL and don't see any where statements, why? Because the provider executes the expression internally and analyzes the output we want, we don't know if the effect is to satisfy our multi-conditional stitching problem.

Because the lambda expression inside the where method is executed, it will not be executed (truck. License-number. LENGTH<10), so this provides an interface for our multi-conditional stitching.

Let's look at an example of a multi-conditional combination query:

After the query entities on the interface are passed into the data access layer:

View Code

This query LINQ is really beautiful, and it is much easier to judge than the previous ifelse.

View Code

If there are a lot of query conditions, then we will write a lot of such judgment code, that is inconvenient and not beautiful.

(Note: See larger image)

or query between multiple conditions

Although in many cases we use the WHERE keyword in LINQ to stitch query conditions, there is a requirement that LINQ queries do not satisfy us that the relationship between multiple conditions is or. As long as we use LINQ or chained methods to write out the Where condition in the SQL statement will be after the and relationship, this time we can only use the chain method to split the line.

View Code

Here is a focus on foreigners (estimated to be more powerful predecessors, here thank you!) Write a *.cs file, which is the extension of the expression<t> expression file, is mainly used for multi-conditional or, and between the combination of queries.

All say that if a multi-conditional combination query is an and relationship that can be used directly with LINQ, if or or either or with and, you can use the chained query method above.

Summary: In fact, so many purposes only one, LINQ parsing process is not only a "provider translation into SQL" process, but includes two stages, four process processing, LINQ many kinds of writing, the principle should be similar, As long as we are considering these processes in writing LINQ, we should be very helpful in dealing with complex queries.

. NET in-depth parsing of LINQ Frameworks (vi: LINQ execution Expressions)