好久沒過來扯淡了，話說這年頭還有偶遇的事情嗎？比如國慶回家的汽車上有個妹子要你QQ，要你微信，想著法子跟你聊天，然后睡了一覺，醒來發現
腎不見了？小花絮小花絮，要是腎真沒了，也吹不了牛，敗不了火了，繼續言歸正傳。
一：擴展方法
說到擴展方法，我想大家都已經再熟悉不過了，也許你的解決方案中有無數個這樣的擴展方法，自從有了Linq之后，我們的集合就再也不單純了。
從下面的Linq類中，所有的方法都擴展在IEnumerable<T>上，恰恰我們的集合都繼承于IEnumerable接口下面。
然后我們在編碼的時候就來了很多這樣的擴展方法。
那么現在問題來了，學挖掘機技術哪家強o(∩_∩)o...？
下面舉一個擴展string類的一個Asint()方法，然后看看IL代碼都干了些什么？
1 namespace Consoleapplication1 2 { 3 class PRogram 4 { 5 static void Main(string[] args) 6 { 7 var s = "123".AsInt(); 8 } 9 }10 11 public static class StringExtension12 {13 public static int AsInt(this string value, int defaultValue = 0)14 {15 int result;16 if (!int.TryParse(value, out result))17 {18 return defaultValue;19 }20 return result;21 }22 }23 }
IL代碼：
從IL的call指令可以看出，其實擴展方法本質上是調用靜態類StringExtension中的AsInt方法，所以可以看出其實這也是編譯器為了提高我們的開發
效率而提供的的一個語法糖而已，所以上面的寫法同樣可以寫成這樣，同樣可以看出下面的寫法就麻煩了很多。
1 s = StringExtension.AsInt("123");
那么下面又來了一個問題，既然可以隨意擴展，那么我能不能擴展string類的任何一個方法？比如說ToLower()？ 從下圖中我們可以得到答案，在vs的智能感
知中顯示出的方法還是string自帶的方法，而不是我擴展的方法，這就說明編譯器在用方法的時候還是有優先級的，正是因為有了這個優先級的問題，給我們
帶來了一個很大的“版本控制問題”，就比如我剛才擴展的Asint()方法，如果后期的CLR版本中在String類中自己增加了Asint()方法的話，那我擴展的Asint()
方法從此就會被忘卻于天涯，所以這個問題要留一點心。
二：分部方法
說起分部方法，你可能會問它有什么應用場景，畢竟在我們實際的編碼中很少使用到，到是分部類用的不少，所以啦，我必須找點場景出來。
恰好在EF中還真給找到了。
具體怎么建一個EF文件就不說啦，我們就看看EF生成的模板代碼。
1 public partial class DataClasses1DataContext : System.Data.Linq.DataContext 2 { 3 4 private static System.Data.Linq.Mapping.MappingSource mappingSource = new AttributeMappingSource(); 5 6 #region 可擴展性方法定義 7 partial void OnCreated(); 8 #endregion 9 10 public DataClasses1DataContext() : 11 base(global::System.Configuration.ConfigurationManager.ConnectionStrings["testConnectionString"].ConnectionString, mappingSource)12 {13 OnCreated();14 }15 16 public DataClasses1DataContext(string connection) : 17 base(connection, mappingSource)18 {19 OnCreated();20 }21 22 public DataClasses1DataContext(System.Data.IDbConnection connection) : 23 base(connection, mappingSource)24 {25 OnCreated();26 }27 28 public DataClasses1DataContext(string connection, System.Data.Linq.Mapping.MappingSource mappingSource) : 29 base(connection, mappingSource)30 {31 OnCreated();32 }33 34 public DataClasses1DataContext(System.Data.IDbConnection connection, System.Data.Linq.Mapping.MappingSource mappingSource) : 35 base(connection, mappingSource)36 {37 OnCreated();38 }39 40 public System.Data.Linq.Table<Student> Student41 {42 get43 {44 return this.GetTable<Student>();45 }46 }47 }
可以看到在幾乎所有的構造函數中都有這樣的一個OnCreated方法，這個具體的OnCreated的實現，你可以自定義一個分部方法來實現。里面可以放些你認
為適應你項目需要的東西，比如：日志，統計啥的。
根據上面EF的例子，我舉個簡簡單單的sample，就是用Log方法來記錄當前登陸該DB的用戶
1 namespace ConsoleApplication1 2 { 3 class Program 4 { 5 static void Main(string[] args) 6 { 7 for (int i = 0; i < 10; i++) 8 { 9 var db = new DB();10 }11 12 Console.Read();13 }14 }15 16 /// <summary>17 /// 比如這是codesmith生成的代碼18 /// </summary>19 public partial class DB20 {21 partial void Log();22 23 public DB()24 {25 Log();26 }27 }28 29 /// <summary>30 /// 自己實現的代碼31 /// </summary>32 public partial class DB33 {34 public static int instanceCount = 0;35 36 partial void Log()37 {38 Console.WriteLine("當前是第{0}個用戶登陸DB", ++instanceCount);39 }40 41 ~DB()42 {43 instanceCount--;44 }45 46 }47 }
再來看看IL：
可以看出在編譯器編譯之后，自動生成的DB和我自定義的DB類已經合二為一了，當然這必須是我們預期的結果，不過這里有一個小注意的地方，如果這
里我沒有實現自定義的Log方法，那么自動生成DB類中的Log方法會何去何從呢？因為它僅僅是定義一個方法的口子，并沒有實現。
1 namespace ConsoleApplication1 2 { 3 class Program 4 { 5 static void Main(string[] args) 6 { 7 for (int i = 0; i < 10; i++) 8 { 9 var db = new DB();10 }11 12 Console.Read();13 }14 }15 16 /// <summary>17 /// 比如這是codesmith生成的代碼18 /// </summary>19 public partial class DB20 {21 partial void Log();22 23 public DB()24 {25 Log();26 }27 }28 }
從上面的圖中可以看到兩點好玩的地方：
①： 已經沒有了Log方法的IL指令，這就說明如果只定義了方法接口而不實現的話，編譯器會直接忽視它。
②： 根據上一條的意思，我們也不難理解為什么在ctor上沒有了log方法，而僅僅是默認調用父類的構造函數，所以編譯器真的很智能。
新聞熱點
疑難解答
