好久没过来扯淡了，话说这年头还有偶遇的事情吗？比如国庆回家的汽车上有个妹子要你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 StringExtension
12 {
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> Student
41 {
42 get
43 {
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 DB
20 {
21 partial void Log();
22
23 public DB()
24 {
25 Log();
26 }
27 }
28
29 /// <summary>
30 /// 自己实现的代码
31 /// </summary>
32 public partial class DB
33 {
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 DB
20 {
21 partial void Log();
22
23 public DB()
24 {
25 Log();
26 }
27 }
28 }
从上面的图中可以看到两点好玩的地方：
①： 已经没有了Log方法的IL指令，这就说明如果只定义了方法接口而不实现的话，编译器会直接忽视它。
②： 根据上一条的意思，我们也不难理解为什么在ctor上没有了log方法，而仅仅是默认调用父类的构造函数，所以编译器真的很智能。
版权声明：本文为博主http://www.zuiniusn.com 原创文章，未经博主允许不得转载。