Linqtodb Source code Analysis--Design principle

We know that the functionality of LINQ to SQL can be used to implement the Iqueryable<t> interface and the Iqueryprovider interface. On how to achieve this, the previous chapter also guided us in a direction. The LINQTODB framework is also in this direction. However, the author of the LINQTODB framework is really very silent. If you have opened the LINQTODB framework source of friends, you may find a lot of code is not text description. This has undoubtedly increased the momentum for those who want to understand the framework in depth. Originally I thought just no relevant code to explain not afraid. There should be no big problem if you find the corresponding document. So I was like a lot of people--to the author of GitHub to find. The result is only to teach you how to use it. There is no explanation for the framework. I think maybe the author is more lazy. It's probably only on his blog that the relevant documentation is available. As a result, I was disappointed-I didn't find anything helpful. Alas! In order to get more information the author also purchased a VPN. So there's only one way to learn about the LINQTODB framework--bite your code. This is obviously the way to find the author's ideas and ideas from the code. At the same time, there is no denying the existence of guessing errors. The author's random piece of code is likely to lead to misleading understanding. I hope readers will understand.

principles of the LINQTODB framework

As mentioned above, the LINQTODB framework is also based on the three steps mentioned in the previous chapter. So our goal has become clear--understand how the LINQTODB framework achieves these three steps.

1. Implement the Iqueryable<t> interface and the Iqueryprovider interface provided by LINQ. Generates a related expression tree. 2. Transform the corresponding expression tree to generate the SQL statement for the corresponding database. and execute. 3. Based on the mapped information, generate the corresponding collection class.

From the example in the previous chapter, we can see that the LINQTODB framework takes the DataContext class as the entry class. This obviously looks like the Entity Framework. is to use a class as the context for the entire framework. If you have seen the example on GitHub, you will find that the entry class used by the author is not the same as the author. The author uses the DataConnection class. In fact, both the DataConnection class and the DataContext class inherit the Idatacontext interface. So in terms of use, not too much. It is only in the author's opinion that there is a big difference between their duties. However, I still do not understand the author's purpose of this design. The DataConnection class can do most things in the DataContext class, but it has its own unique responsibility--to access the information of the current database. Let the author feel that the DataConnection class in the responsibility of a little repetition. This is why I think the DataContext class is the LINQTODB framework entry class. At least let the author think DataContext class is more clear.

The above picture depicts a schematic of the LINQTODB framework at query time. is the author according to the Code of the operation of the line to sort out. The main purpose is to facilitate the guidance of everyone in-depth, less go a little detour. We know it's easy to implement a LINQ query, which is the three steps above. But there are a lot of things to achieve in these three steps. The image shows only the main core cuts. It can be said that these three steps is to rely on the image of the class to work.

Load Data library information

The LINQTODB framework does not hand out classes that implement iqueryable<t> and Iqueryprovider directly. But in the context of the way of thinking indirectly guided out. This is also a reasonable design. We need to know about the database before we build the expression tree and the SQL statement. For example, what is the current database with--sql server or MySQL? And this task is given to the DataConnection in the picture. This means that the LINQTODB framework has already known the information about the database when it enters the first step above. However, the author does not directly set the database information. Instead, it is provided through an Idataprovider interface instance. This looks more like the DataContext class is just the responsibility for booting. If you have used additions or deletions, you may feel wrong. He is not allowed to delete and change it? In fact, if you put your heart to it, they're all static extension methods.

building an expression tree

With the DataContext class we can get our collection table (the Set table here refers to an instance that implements the Itable interface). The Itable interface is similar to the Idbset interface of the Entity Framework. From the code we may see that he comes from the Iexpressionquery interface. I believe you can see the name of the Iexpressionquery interface implementation class is the Expressionquery class in the picture. This time the first step of the work began. The Expressionquery class is the corresponding class that implements the Iqueryable<t> interface and Iqueryprovider interface. Of course, the LINQTODB framework uses the sub-interface--iorderedqueryable<t> of the Iqueryable<t> interface. The work to build the expression tree is also here to begin.

Execute Database

The main difficulty in implementing a LINQ query is how to handle the expression tree, generating the corresponding T-SQL from the expression tree. The LINQTODB framework uses a core class of query to make intermediate excesses. I like to call him the middle person. When designing a query class, the author does not directly instantiate it. Instead, the ExpressionBuilder class is further processed to assign the relevant information to the query class instance, returning the query class instance. So it is very difficult for the author to make a clear statement with one or two words for the ExpressionBuilder class. It can only be said that he is used to deal with the expression tree. One has to use a class called SelectQuery. This class is very important. He will be involved in the final generation of T-SQL work. I want to say that through the ExpressionBuilder class processing, the corresponding query or additions and deletions will be recorded in the SelectQuery class instance. The equivalent of generating T-SQL information is stored in the SelectQuery class instance.

The job responsibilities of the query class are more complex. The query class has the ability to generate T-SQL when it has gone through the process of processing an expression tree. Why do you say that? At this time, the query class has mapping information for the SelectQuery class instance and result set that generates T-SQL MapInfo class instance. So generating T-SQL is just a matter of time. The process of generating T-SQL looks simple, but in fact there are a lot of details to deal with. The author allows the LINQTODB framework to call the subclass of the Basicsqlbuilder class to handle the generation of T-SQL through the DataConnection class. Of course, this process can not be separated from the SelectQuery class. Only the author does not commit T-SQL directly, but instead generates an instance called the Preparedquery class. The Preparedquery class is used to hold information about the execution database. This is the last step. The Xxxcommand class execution database is generated from the Preparedquery class instance. The MapInfo class instance is converted to the corresponding collection data.

Concluding remarks

All right. For the LINQTODB framework of the principle of the author is introduced here. The later chapters of this series are also based on the ideas in this chapter. See what the author looks like to design the LINQTODB framework. What is worth learning from us.

Linqtodb Source code Analysis--Design principle