LINQ的演变及其对C#设计的影响(3)

匿名类型

如果我们想继续使用我们现有的语法来返回名称和地址，我们很快便会面临问题，即不存在仅包含Name和Address的类型。虽然我们仍然可以编写此查询，但是必须引入该类型：

class CustomerTuple
{
　public string Name;
　public string Address;
　public CustomerTuple(string name, string address)
　{
this.Name = name;
this.Address = address;
　}
}

然后我们才能使用该类型，即此处的CustomerTuple，以生成我们查询的结果。

IEnumerable locals =customers.Where(c => c.ZipCode == 91822).Select(c => 
   new CustomerTuple(c.Name, c.Address));

那确实像许多用于投影出字段子集的样板代码。而且还往往不清楚如何命名此种类型。CustomerTuple确实是个好名称吗?如果投影出Name和Age又该如何命名?那也可以叫做CustomerTuple。因此，问题在于我们拥有样板代码，而且似乎无法为我们创建的类型找到任何恰当的名称。此外，还可能需要许多不同的类型，如何管理这些类型很快便可能成为一个棘手的问题。

这正是匿名类型要解决的问题。此功能主要允许在无需指定名称的情况下创建结构化类型。如果我们使用匿名类型重新编写上述查询，其代码如下所示：

locals = customers.Where(c => c.ZipCode == 91822)
　.Select(c => new { c.Name, c.Address });

此代码会隐式创建一个具有Name和Address字段的类型：

class
{
　public string Name;
　public string Address;
}

此类型不能通过名称引用，因为它没有名称。创建匿名类型时，可显式声明字段的名称。例如，如果正在创建的字段派生于一条复杂的表达式，或纯粹不需要名称，就可以更改名称：

locals = customers.Where(c => c.ZipCode == 91822)
.Select(c => new { FullName = c.FirstName + “ “ + c.LastName,
HomeAddress = c.Address });

在此情形下，生成的类型具有名为FullName和HomeAddress的字段。

这样我们又向理想世界前进了一步，但仍存在一个问题。您将发现，我在任何使用匿名类型的地方都策略性地省略了局部变量的类型。显然我们不能声明匿名类型的名称，那我们如何使用它们?

隐式类型化部变量

还有另一种语言功能被称为隐式类型化局部变量(或简称为var)，它负责指示编译器推断局部变量的类型。例如：

var integer = 1;

在此例中，整数具有int类型。请务必明白，这仍然是强类型。在动态语言中，整数的类型可在以后更改。为说明这一点，以下代码不会成功编译：

var integer = 1;
integer = “hello”;

C#编译器将报告第二行的错误，表明无法将字符串隐式转换为int。

在上述查询示例中，我们现在可以编写完整的赋值，如下所示：

var locals =
customers
.Where(c => c.ZipCode == 91822)
.Select(c => new { FullName = c.FirstName + “ “ + c.LastName,
HomeAddress = c.Address });

局部变量的类型最终成为IEnumerable＜?＞，其中“?”是无法编写的类型的名称(因为它是匿名的)。

隐式类型化局部变量只是：方法内部的局部变量。它们无法超出方法、属性、索引器或其他块的边界，因为该类型无法显式声明，而且“var”对于字段或参数类型而言是非法的。

事实证明，隐式类型化局部变量在查询的环境之外非常便利。例如，它有助于简化复杂的通用实例化：

var customerListLookup = new Dictionary＜STRING, ListCustomer＞();

现在我们的查询取得了良好进展;我们已经接近理想的语法，而且我们是用通用语言功能来达成的。

有趣的是，我们发现，随着越来越多的人使用过此语法，经常会出现允许投影超越方法边界的需求。如我们以前所看到的，这是可能的，只要从Select内部调用对象的构造函数来构建对象即可。但是，如果没有用来准确接受您需要设置的值的构造函数，会发生什么呢?