本身動手寫ORM的感覺

  以前看到奮鬥前輩和時不我待前輩的本身動手寫ORM系列博客，感受講解的通俗易懂，清晰透徹。做爲一個菜鳥，閒來也想着本身寫一個ORM，一來加深本身對 ORM的理解，以求對EF，NHibernate等ROM框架的使用能更加輕車熟路。二來也可在寫ORM之時熟悉反射的應用場景，反射的優缺點，優化方 法，Lambda表達式，表達式樹等。，對本身也是一個不錯的鍛鍊。

   ORM的原理也就表映射，反射，拼接sql，緩存，Lambda進行方法調用。網上有不少源碼參考和原理講解，對着敲一敲完成一個簡易的ORM並非什麼很難的事。

本身寫以前對反射還算熟悉，因此從表映射，反射，拼接sql一路走來倒也沒有什麼很難理解的。寫完第一個加載表數據的時候，也的確發現了反射用的太 多，太依賴反射，取值，賦值，調用。衆所周知，反射是會有必定的性能消耗的，雖然一次使用的影響很小，但關鍵是量多啊，量變引起質變。

   做爲一個程序員，對每一絲可優化的代碼有會想要去優化。因而我就去找資料啊，看各位大神的文章啊，看到有人介紹Lambda，有人介紹CodeDom,有 人介紹Emit，這麼多選擇我該選擇什麼呢?又是找了一番資料，最後選擇了Lambda去優化。選好了優化手段，該去實現了，因而問題出現了，用 Lambda構建表達式樹，生成委託，調用，對於一個不多寫委託的菜鳥，看着源代碼實在難以理解，看了幾遍頭都痛了。沒辦法，找資料，補全本身的知識。找 Demo,寫例子，一條語句一條語句啃，慢慢的，也就稍微能理解源代碼裏各個方法，各個語句的做用了，對利用lambda優化的思路也開始清晰了。

   ORM還在寫，源碼就不放上來了，菜鳥寫的菜。ORM的例子，源碼，講解網上的文章很多，本身有興趣找一下不會很難的。

   下面是我設置屬性值的代碼，窺一斑而知全豹。

    static Func<T, object, object> GetSetDelegate<T>(MethodInfo methodInfo,Type type)  
           {  
               //設置參數節點  
               var param_obj = Expression.Parameter(typeof(T), "obj");  
               //設置參數節點值  
               var param_val = Expression.Parameter(typeof(object), "val");  
               //轉換類型  
               var body_val = Expression.Convert(param_val, type);  
               //表達式方法體  
               var body = Expression.Call(param_obj, methodInfo, body_val);  
               //生成Lambda表達式的委託  
               Action<T, object> set = Expression.Lambda<Action<T, object>>(body,param_obj, param_val).Compile();  
               //返回委託  
               return (instance, v) => { set(instance, v); return null; };  
           }  
      
           static void FastSetValue<T>(this PropertyInfo prop, T t, object val)  
           {  
               //獲得屬性寫方法  
               MethodInfo m = prop.GetSetMethod();  
               //調用方法  
               GetSetDelegate<T>(m, prop.PropertyType)(t, val);  
           }  

菜鳥的理解可能不能入大神們的眼，若是我理解的有錯誤，或有誤差，還請大神們能不吝指教。