不能不说的C#特性-匿名类型与隐式类型局部变量
系列文章导航：
不能不说的C#特性-迭代器(下)，yield以及流的延迟计算
走进Linq-Linq to SQL How do I(1)
走进Linq-Linq to SQL How do I(2)
走进Linq-Linq to SQL How do I(3)
走进Linq-Linq to SQL源代码赏析 Table
走进Linq-Linq to SQL源代码赏析之Provider的初始化
走进Linq-Linq to SQL源代码赏析，通过Linq to SQL看Linq
在本篇中我要介绍两个概念，我觉得这两个东西必须一起来介绍，这样才能连贯。
C# 2.0里我们已经匿名方法了，现在类型也玩起匿名来了，怪不得大家“举报”的时候都喜欢匿名，为啥？因为匿名被举报人就找不着报复对象了呗，是的，匿名就是把名字隐藏起来，没有名字谁还能找得到你啊。
匿名类型
在C#里有这样一些类型，它是作为临时储存数据的，生命周期只在这个方法内，方法结束了，这个类型的生命周期也没有了。那么这里我们就可以使用一个匿名类型。
这个KeyPair就是一个匿名类型，注意KeyPair这里是一个变量名，并不是类的名字。嗯，前面还有一个var，这又是什么呢？这是C# 3.0里面的隐式局部变量。
隐式类型局部变量
还是先介绍一下隐式类型局部变量吧：
在C# 3.0里多了一个关键字var,他表示这样的一种类型：C#编译器可以根据上下文推断的出来 比如var I = 5;编译器可以根据后面的赋值推断的出来i应该是个整型。既然是局部变量，那么它就只能用在方法内部了，注意C#是强类型的，引入了一个var并不是像javascript那样，变成了一个弱类型的语言。在编译器第一次编译后var就会被确定的类型所替代的。所以对于隐式类型局部变量要注意以下几点：
1.它只能存在于方法内部
2.它不是一个新的类型，只是一个关键字，或者叫做一个占位符，在C#编译器编译后它就会被确定的类型所替代
3.它是编译器根据上下文推断出来的，所以所有一切不能被编译器推断出来的用法都是错误的。比如不能这样使用：var nullValue = null;因为null啥也不是，他是一个空指针，是一个不确定的东西。也不能这样使用：var I = 5;I = “abc”;编译器根据第一个赋值会推断出它是一个整型，但是随后又将一个字符串赋值给它，这是怎么回事呢？
对于var我的建议是不到逼不得已的时候不用，那什么是逼不得已呢？来看我们的匿名类型吧。
回到匿名类型
刚才说了，匿名类型是没有名字的类型，没有名字你怎么来称呼它，怎么来声明它？但是匿名类型真的是没有名字的么？
看看C#编译器又在我们背后干了些什么：
使用ILDASM打开编译过的程序集，发现多了一个类型：
这个类型是直接继承自System.Object的，并且是internal seald(只在程序集内可见，并且不能被继承)。有心的你也许会发现，这个类型还是一个泛型类型，那么只要我们在使用一个匿名类型的时候参数个数，参数名称不发生变化，编译器是不会为我们产生更多的类型的：
var KeyPair2 = new { Key="y",Value=3};
var KeyPair3 = new { Key=4,Value="abc"};
上面三个匿名类型，编译器只会为我们在背后产生一个新类型，一个泛型的新类型。如果我们将这个匿名类型内的属性名修改一下：对
var KeyPair2 = new { Key="y",Value1=3};
就会产生两个新泛型了：
<>f__AnonymousType1<<Key>j__TPar, <Value1>j__TPar>
看看，这个命名还是有规律可循哦。 如果你给这个匿名类型添加一个新属性呢？ 这样又产生了一个新类型了：
嗯，这个问题还是值得关注的，所以我们在使用匿名类型的时候应该尽量保持“一致性”：
属性个数一致(这个尽量了)。
属性名称一致，这个比较好把握。
只要保持了这个一致性，编译器会为一致的产生同一个类型，而不一致的会新产生一个类型，如果不一致的太多我想是不是会产生“代码爆炸”而致使”WorkSet”过大造成性能的损失？这个只是我个人认为，没有经过测试。
继续隐式类型局部变量
由于匿名类型在我们编写代码的时候并不存在，所以匿名类型也不能作为方法的返回值和参数了。”var”一样，也是只能在方法内部使用。现在是不是有点明白什么时候才是逼不得已使用”var”啊？就是在使用匿名类型的时候，匿名类型编译器可以推断出来，但是靠人工又无法推断了。所以我觉得只在编译器可推断而人不可推断的时候才使用隐式类型局部变量，靠我们人工可以推断的还是不建议使用，显式的声明变量类型可以增强代码的可读性，这是一个好的编程习惯，不要因为C# 3.0提供了这样的特性就大用而特用。
