September 10, 2020 LINQ framework written LINQ framework (four: IQueryProvider interface details)

1. Introduction

Let me interrupt before I start reading this article. In fact, this article was not intended to include the section of “introduction”, but later I thought it was necessary to give feedback to readers. After the detailed explanation of the first three articles, we basically have a basic understanding of the LINQ framework, including its design model, object model, and so on. We know that LINQ query expression is actually a syntax sugar above C#, but this sugar is really good, very convenient and timely. A series of LINQ support principles are introduced in a wide range of theories, do not know the effect;

At the end of my last post, I saw a senior comment suggesting that I write more about the use of LINQ rather than these theories. By the way, I take this opportunity to explain that THERE are so many LINQ usage articles on the Internet that there is no need or value to write about them. There are so many LINQ usage articles on the Internet, from beginners to complex applications, that programmers of all levels can find articles for them. I think these articles belong to use classes, when used in practical projects slightly can check up line, and is important to understand the principle of which is our long-term pursuit, because these principles in the design of any application framework are interlinked, can help us to extrapolate learning, reduce the learning cost, Constantly improve the internal design ideas.

The so-called design ability reflects the level of technology, it is true. Comrades, our constant pursuit should be design, not just use. When you understand the principle, I think everyone can come up with different application directions, then the development of technology makes sense, of course, this is the most valuable.

2. Extending Linq to Object (application framework with query function)

/// <summary> 
///Order type
/// </summary> 
public class Order 
{ 
    /// <summary> 
    ///Name of the order
    /// </summary> 
    public string OrderName { get; set; } 
    /// <summary> 
    ///Place the order of time
    /// </summary> 
    public DateTime OrderTime { get; set; } 
    /// <summary> 
    ///The order no.
    /// </summary> 
    public Guid OrderCode { get; set; }}Copy the code

public static class OrderCollectionExtent 
    { 
        public static bool WhereOrderListAdd<T> (this IEnumerable<T> IEnumerable) where T : Order 
        { 
            foreach (var item in IEnumerable) 
            { 
                if(item.OrderCode ! =null&&! String.IsNullOrEmpty(item.OrderName) && item.OrderTime ! =null) 
                { 
                    continue; 
                } 
                return false; 
            } 
            return true; }}Copy the code

List<Order> orderlist = new List<Order>() 
            { 
                new Order(){ OrderCode=Guid.NewGuid(), OrderName="Fruit", OrderTime=DateTime.Now}, 
                new Order(){ OrderCode=Guid.NewGuid(), OrderName="Office supplies",OrderTime=DateTime.Now} 
            }; 
            if (orderlist.WhereOrderListAdd()) 
            { 
                // Perform the insert
            }
Copy the code

public class OrderCollection : IEnumerable<Order> 
   { 
       List<Order> orderList; 
       public OrderCollection() 
       { 
           orderList = new List<Order>() { 
               new Order(){ OrderCode=Guid.NewGuid(),OrderName="Order", OrderTime=DateTime.Now}, 
               new Order(){ OrderCode=Guid.NewGuid(),OrderName="The order 2", OrderTime=DateTime.Now}, 
               new Order(){ OrderCode=Guid.NewGuid(),OrderName="The order 3", OrderTime=DateTime.Now} 
           }; 
       } 

       public IEnumerator<Order> GetEnumerator() 
       { 
           foreach (var order in orderList) 
           { 
               yield return order; 
           } 
       } 
       System.Collections.IEnumerator System.Collections.IEnumerable.GetEnumerator() 
       { 
           foreach (var order in orderList) 
           { 
               yield returnorder; }}}Copy the code

public static OrderCollection GetOutOrderCollection(this OrderCollection OrderColl) 
       { 
           return OrderColl; 
       }
Copy the code

3… Realize the IQueryable and IQueryProvider interfaces

The focus of this article is to explain the IQueryable and IQueryProvider two interfaces, when we understand the two interfaces, we can be imaginative to implement any data source queries. IQueryable, IQueryProvider two interfaces still have a lot of good things worth our study, which is full of a large number of design patterns, data structure knowledge, we will slowly analyze its beauty.

The IQueryable interface is an entry point to the Linq to Provider. Interestingly, it is not an IQueryable interface that supports a query. When we write Linq statements, we usually write where something and then SELECT something, at least two consecutive extension method mapping calls, but do you know how it’s handled internally? How do they associate a full query whenever A Where is followed by a Select? IQueryable is not an IEnumerable object that can be processed in real time and returned to the next method. So how does it string fragmented execution methods together into a whole, complete query? Now we will analyze the patterns, data structures and framework principles involved one by one. After understanding these, the code is the representation of the model, and it will be understood naturally.

Lazy loading was a technique that predated Linq, but it was largely hidden in the system framework. There are many occasions when we need to build in the lazy loading feature ourselves. Building delay in an IEnumerable object basically uses yield Return to build a state machine that only returns data when iterating. The data is obtained by executing the Provider program in IQueryable, reducing the performance cost of obtaining the data in the first place. The IQueryable inherits from the IEnumerable interface, which is called by the Foreach syntax, but executes the provider’s code in the GetEnumerator method. Let’s examine the code of the IQueryable interface.

public IEnumerator<T> GetEnumerator() 
       { 
           return (Provider.Execute<T>(Expression) as IEnumerable<T>).GetEnumerator(); 
       } 

       System.Collections.IEnumerator System.Collections.IEnumerable.GetEnumerator() 
       { 
           return (Provider.Execute(Expression) as IEnumerable).GetEnumerator(); 
       }
Copy the code

The IQueryable interface returns the IEnumerator interface type inherited from IEnumerator. Both Linq to Sql and Linq to Entity return strongly-type collection objects, which generally do not query data in real time. . If you want to perform real-time require IQueryable Provider. Direct call the Execute method.

We use the diagram to analyze the principle of lazy loading in Linq to Provider.

This code will not be executed immediately, so let’s trace the execution between the components;



This figure focuses on the continuous operations of the IQueryable object. The idea is that each time an extension method is implemented, a new IQueryable object is created, which contains the expression tree that was executed last time, and so on. Detailed principles are analyzed in the following sections.

Finally, the Orderlist will be an object of type IQueryable that contains the full expression tree and will not trigger data queries unless used. This is the key to lazy loading. If you want to retrieve data can be performed manually in the orderlist immediately orderlist. The Provider. The Execute < TB_Order > (orderlist. Expression) to obtain the data.

3.2】. There is a trap that occurs when source code is analyzed that focuses on the underlying parameters of the extensible methods rather than the objects themselves, and that seemingly different methods are located at different locations. In fact, they come from the same place, where the logical object is the same, but this will just cause us to analyze the bottleneck of the problem, here we focus on the extension method to expand the object.

We directly use the source code to explain it;

public static IQueryable<TResult> Select<TSource.TResult> (this IQueryable<TSource> source, Expression<Func<TSource, TResult>> selector) 
{ 
    if (source == null) 
    { 
        throw Error.ArgumentNull("source"); 
    } 
    if (selector == null) 
    { 
        throw Error.ArgumentNull("selector"); 
    } 
    return source.Provider.CreateQuery<TResult>(Expression.Call(null, ((MethodInfo) MethodBase.GetCurrentMethod()).MakeGenericMethod(new Type[] { typeof(TSource), typeof(TResult) }), new Expression[] { source.Expression, Expression.Quote(selector) })); 
}
Copy the code

This is the source code for the Select extension method of the Queryable class that extends the IQueryable object and operates internally using the Source object, which is a direct reference to the extension object. This is the focus of the issue. Sources that are not familiar with the extended method and chained programming can be difficult to concatenate to IQueryable objects returned by previous methods. Source represents each IQueryable instance, and the object that is currently invoked, no matter how many invocations are made, so the invocations are consistent, much like a bidirectional list. And then the next method will all be a method of this object. So note that this call will follow the last one, not start with a new one. Understanding this is critical for the LINQ analysis that follows.



3.3】. Segmenting implementation of sub-methods at Queryable (extension methods at Queryable)

Linq query is known to be a number of keywords splicing together, line into continuous query semantics, which is behind the principle of the article up and down also said many times, I think it should be roughly understood. In fact, this is a bit like breaking a big problem into many small problems to solve, but not all for the purpose of solving the problem and so on. In chained query, many keywords are common in different query contexts, such as where can be used in the query, can also be used in the update, delete. The issues discussed here may go beyond LINQ, but it makes sense because they share a similar design model.

According to figure 3.2, we already know that objects transferred between extension methods are from different instances but from the same object type, so why perform each keyword operation in segments? Let’s use diagrams to help us analyze the problem.



Both lines of code refer to the Where method, and both require concatenation conditions, but the conditions generated by the Where method do not affect your previous methods. This is where the benefit of piecewise execution comes in: maximum granularity of decoupling for maximum reuse.

3.4】. Design error of chain query method (key: When using iqueryyable, we attempt to analyze source code to help generate expression tree data over the internal use mechanism of iqueryyable, we naturally see the Provider property, the property is the IQueryProvider interface, The annotations clarify that it is the last provider to execute the query, and that the initial instance of the IQueryable is regarded as the entry point to the query, maintains a unique instance throughout the extended method invocations, and finally acquires all expressions, forming an expression tree. But IQueryable plays a joke by invoking CreateQuery, which is returned over a number of times. It looks like a single execution with multiple method calls hidden behind it, creating an execution model that we didn’t even know existed, and making people ecstatic. Let’s take a look at how yable IQueryable is dealt with in the chain approach and see how much it can be hidden.

public static IQueryable<TSource> Where<TSource> (this IQueryable<TSource> source, Expression<Func<TSource, bool>> predicate) 
{ 
    if (source == null) 
    { 
        throw Error.ArgumentNull("source"); 
    } 
    if (predicate == null) 
    { 
        throw Error.ArgumentNull("predicate"); 
    } 
    return source.Provider.CreateQuery<TSource>(Expression.Call(null, ((MethodInfo) MethodBase.GetCurrentMethod()).MakeGenericMethod(new Type[] { typeof(TSource) }), new Expression[] { source.Expression, Expression.Quote(predicate) })); 
}
Copy the code

Similar to this section of code in the article has appeared above, much the same, we below detailed analysis of its internal principle, in the end is how to build a dynamic is static object model.

This method takes one parameter, which is a conditional expression, and extends the IQueryable interface, which can be used by any derivatives. The return type of the method is also the IQueryable type. The same return type and extension type constitute the minimum loop of chained programming. There are two judgments in the method. The first is to determine whether the code is called by extension methods, preventing us from using extension methods directly, and the second is to determine whether we provided expressions.

So what does the last line of code, which wraps several layers of method calls, really mean? When we break it down in detail, the light suddenly dawns on us.



Due to the complexity of the issue, a comprehensive context analysis of the IQueryable is not provided here. The integrity of this section is ensured. The IQueryable object is an object that each method invocation creates a new instance, which is then automatically accepted and invoked by the next method.

Interface-oriented design seeks separation of responsibilities. Why place the implementation and creation of IQueryProvider over the IQueryProvider? It would be more ingenious if the IQueryable extraction process were to be a separate creation interface, although this is my guess and may be a misunderstanding.