處理表達(dá)式樹可以說是所有要實(shí)現(xiàn)Linq To SQL的重點(diǎn)，同時(shí)他也是難點(diǎn)。筆者看完作者在LinqToDB框架里面對(duì)于這一部分的設(shè)計(jì)之后，心里有一點(diǎn)不知所然。由于很多代碼沒有文字注解。所以筆者只能接合上下代碼來推斷出作者大概在做什么。但是有些筆者只知道在做什么卻很難推斷出作者為什么要這么做。這一部分的主要核心類有倆個(gè)——Query<T>類和ExpressionBuilder類。可以用一句話來形容：由Query<T>類起也由Query<T>類落。

處理優(yōu)化表達(dá)樹

上一章我們能知道執(zhí)行最后的操作一定是要通過Query<T>類實(shí)例來完成的。而Query<T>類又必須通過ExpressionBuilder類來獲得的。很顯然他們倆個(gè)之間的關(guān)系很復(fù)雜。但是有一點(diǎn)可以肯定——最后的工作都會(huì)交給Query<T>類的GetElement方法和GetIEnumerable方法。在Query<T>類的構(gòu)造函數(shù)里面一開始就把GetIEnumerable方法賦于MakeEnumerable方法。 

public Query()
{
    GetIEnumerable = MakeEnumerable;
}

也許是筆者理解上的錯(cuò)誤——發(fā)現(xiàn)GetIEnumerable最后還會(huì)被別的方法取代。也就是說MakeEnumerable方法并沒有被執(zhí)行。但是MakeEnumerable方法的作用卻明顯就調(diào)用GetElement方法最后轉(zhuǎn)化成需要的結(jié)果?？梢钥闯鰧?duì)于實(shí)例化Query<T>類并沒有過多復(fù)雜的操作。但是獲得Query<T>類實(shí)例卻要用自身的靜態(tài)方法GetQuery來進(jìn)行。如果直接實(shí)例Query<T>類的話，筆者也不覺得復(fù)雜。主要是他還要通過ExpressionBuilder類的進(jìn)行加工。這一點(diǎn)讓筆者有一種深入迷宮的快感。去掉那些緩存代碼。讓我們把重點(diǎn)移到迷宮口。

Query<T>類： 

 query = new ExpressionBuilder(new Query<T>(), dataContextInfo, expr, null).Build<T>();

ExpressionBuilder類的構(gòu)造函數(shù)的參數(shù)很簡(jiǎn)單——Query<T>類實(shí)例、數(shù)據(jù)上下文信息、當(dāng)前表達(dá)式樹。最后一參數(shù)跟LinqToDB框架的另一個(gè)功能有關(guān)系——CompiledQuery功能。所以如果你一直用Linq To SQL的話，最后一個(gè)參數(shù)一直是null。參數(shù)理解起來并不難?？墒菢?gòu)造函數(shù)里面的代碼卻讓筆者很頭痛。筆者只能知道做什么卻很難理解為什么要這樣子做。

我想了解如何學(xué)習(xí)

姓名：
手機(jī)：
留言：