Talking about the caching of Expression trees (1): Introduction

The expression tree (Expression) is an expression introduced in. NET 3.5. The expression tree is widely used, and it can visualize various "data", even "logic" and "behavior". Furthermore, the expression tree is strongly typed, so using this new feature properly can make code writing elegant and convenient. One of the simplest and most common examples is that some friends now prefer to use expression trees instead of traditional byxxx methods, especially when accessing data sources that directly support expression trees (such as IEnumerable or LINQ to SQL). As follows:

Public User GetUser (Expression<func<user, bool>> predicate) {}

Without having to write:

public　User　GetUserByID(int　id)　{　}
public　User　GetUserByName(string　name)　{　}

You can then invoke the following:

var　user1　=　GetUser(u　=>　u.UserID　==　1);
var　user2　=　GetUser(u　=>　u.Name　==　"jeffz");

Regardless of whether this design is appropriate (because even if it is unreasonable and does not represent all usage), we first agree that the expression tree is useful-so our next topic will look more valuable: P. So how do you cache in a method when you use an expression tree for the above question? In the case of Byid or byname, we can easily construct some strings as cached keys, such as "getuserbyid_100" or "GETUSERBYNAME_JEFFZ". But what now? A different expression object is generated each time the call is made, even if we are "consistent" and cannot be "identified" as the same object, but directly as a cached key, so it is not straightforward to handle it.

You might say, then, when parsing the expression tree, identify whether it is Byid or byname, and then splice out the previous string. Of course, if you really want to solve the problem of the above example, then you can do so in this way. But Mr. Zhao now hopes to find a more generic solution that can be cached based on the expression tree--in fact, that's what old Zhao did when he designed a generic feature, and it's going to be shared with everyone after a detailed discussion of the caching problem.

This caching problem looks simple, but in fact there are a number of strategies that can be selected after performance and functionality are weighed. Lao Zhao will be here to talk about 5 caching strategies, they are different, some of the resources are very provincial, performance is very good, and some of the performance is relatively backward, resource consumption is relatively high, but in some scenarios it seems to be the only solution. So at least I think it's interesting to talk about this, and to some extent, these reflections can give some degree to the beauty of algorithmic design and data structures (although they are relatively simple in fact).

In this series of articles, Mr Zhao hopes to recreate the full path of thought that he has formed when he thinks about the problem. This may be more valuable than the final solution. The article sometimes will be friends "lead astray", the purpose is also to let the brothers experience the old Zhao walked the detour. In the end, you can say "This dead fat man really stupid, how early did not think of" (hehe, everybody mo Strange). In addition, these 5 caching strategies are not the whole of thinking, in fact, Lao Zhao believes there will be a better solution (at least in theory), and for a variety of reasons not to be implemented here. Therefore, Lao Zhao also hope that after reading the article can think together, and talk about your views. :)