1. automatic property
以前 我们 写属性 需要 这样写:
public string LastName {
get {
return _lastName;
}
set {
_lastName = value;
}
现在 只需要
public string LastName {
get; set;
}
C#编译器遇上象上面这样的空的get/set属性的话,它会自动为你在类中生成一个私有成员变量,对这个变量实现一个公开的getter 和setter。这么做的好处是,从类-合同(type-contract)的角度来看,这个类跟我们上面第一个有点冗长的实现看上去完全一样,这意味着,不象公开的成员变量,在将来,我可以在我的属性setter实现中添加验证逻辑,而不用对引用我的类的任何外部组件做改动。
2. 对象初始化器
看了以下代码就明白了
Person person = new Person {
FirstName = "Scott",
LastName = "Guthrie"
Age = 32,
Address = new Address {
Street = "One Microsoft Way",
City = "Redmond",
State = "WA",
Zip = 98052
}
};
3.集合初始化器
List<Person> people = new List<Person> {
new Person { FirstName = "Scott", LastName = "Guthrie", Age = 32 },
new Person { FirstName = "Bill", LastName = "Gates", Age = 50 },
new Person { FirstName = "Susanne", LastName = "Guthrie", Age = 32 }
};
4.什么是扩展方法 (Extension Methods)? (来自Scott)
扩展方法允许开发人员往一个现有的CLR类型的公开契约(contract)中添加新的方法,而不用生成子类或者重新编译原来的类型。扩展方法有助于把今天动态语言中流行的对duck typing的支持之灵活性,与强类型语言之性能和编译时验证融合起来。
扩展方法促成了好多有用的使用场景,并使在作为Orcas一部分发布的.NET版本中引进的非常强大的LINQ查询框架成为可能。
简单的扩展方法例子:
有没有想过要检查一个字符串变量是否是个合法的电子邮件地址? 在今天,你大概需要通过调用一个单独的类(或许通过一个静态方法)来实现检查该字符串变量是否合法。譬如,象这样:
if ( EmailValidator.IsValid(email) ) {
}
而使用C#和VB中的新“扩展方法”语言特性的话,我则可以添加一个有用的“IsValidEmailAddress()”方法到string类本身中去,该方法返回当前字符串实例是否是个合法的字符串。然后我可以把我的代码重写一下,使之更加干净,而且更具描述性,象这样:
if ( email.IsValidEmailAddress() ) {
}
我们是怎么把这个新的IsValidEmailAddress()方法添加到现有的string类里去的呢?我们是通过定义一个静态的类型,带有我们的“IsValidEmailAddress”这个静态的方法来实现的,象下面这样:
{
public static bool IsValidEmailAddress( this string s)
{
Regex regex = new Regex( @"^[\w-\.]+@([\w-]+\.)+[\w-]{2,4}$" ) ;
return regex.IsMatch(s) ;
}
}
注意,上面的静态方法在第一个类型是string的参数变量前有个“this”关键词,这告诉编译器,这个特定的扩展方法应该添加到类型为“string”的对象中去。然后在IsValidEmailAddress()方法实现里,我可以访问调用该方法的实际string实例的所有公开属性/方法/事件,取决于它是否是合法电子邮件地址来返回true/false。
在我的代码里把这个特定的扩展方法的实现添加到string实例,我只要使用标准的“using”语句来引入含有该扩展方法的实现的命名空间:
然后编译器就会在任何string上正确地定位IsValidEmailAddress()方法。在公开发行的Orcas三月份的CTP中的C#和VB在Visual Studio代码编辑器里对扩展方法提供了完整的intellisense支持。所以,当我在一个字符串变量上点击“.”关键词时,我的扩展方法现在就会出现在intellisense的下拉框里:
VB和C#编译器也会很自然地给与你对所有扩展方法用法的编译时的检查,这意味着你会得到一个编译时错误,假如你键错或者错用一个扩展方法的话。
[感谢David Hayden,是他在去年的一个老帖子 里第一个示范了我在上面使用的这个IsValidEmailAddress使用场景。]
扩展方法使用场景续...
利用扩展方法这个新特性来给个别类型添加方法给开发人员开辟了许多有用的扩展性使用场景。但使得扩展方法非常强有力的是,它们不仅能够应用到个别类型上,也能应用到.NET框架中任何基类或接口上。这允许开发人员建立种种可用于整个.NET框架的丰富的可组合的框架层扩展。
譬如,考虑这样一个场景,我想要一个既容易,描述性又强的方式来检查一个对象是否已经包含在一个对象集合或数组里。我可以定义一个简单的.In(集合)扩展方法,我想把它添加到.NET框架中的所有对象上,我可以在C#里这么来实现这个“In()”扩展方法:
注意上面我是如何声明扩展方法的第一个参数的:“this object o”。这表明,这个扩展方法应该适用于继承于基类System.Object的所有类型,这意味著我可以在.NET中的每个对象上使用它。
上面这个“In”方法的实现允许我检查一个指定的对象是否包含在作为方法参数传入的一个IEnumerable序列中。因为所有的.NET集合和数组都实现了IEnumerable接口,现在我拥有了一个有用的,描述性强的方法来检查一个任意的对象是否属于任何.NET集合或数组。
然后我就可以使用这个“In()”方法来看一个特定的字符串是否在一个字符串数组中:
我也可以用它来检查一个特定的ASP.NET控件是否在一个容器控件集合里:
我甚至可以将其用在象整数这样的标量数据类型上:
注意上面,你甚至可以在象整数值42这样的基本数据类型值上使用扩展方法。因为CLR支持数值类型的自动boxing/unboxing,扩展方法可以直接使用在数值和其他标量数据类型上。
你大概可以开始从上面的例子中看出,扩展方法可以促成一些非常丰富和描述性强的扩展性使用场景。当使用于.NET中常见的基类和接口上时,他们可以促成一些非常好的特定于某个领域(domain specific)的框架和组合使用场景。
内置的System.Linq扩展方法
一个在Orcas时段随.NET发布的内置的扩展方法库是一套允许开发人员对任何数据进行查询的非常强有力的查询扩展方法。这些扩展方法实现位于新的 System.Linq 命名空间之下,定义了标准的查询操作符扩展方法,可以为.NET开发人员用来轻松地查询XML,关系数据库,.NET 对象, 和任何其他数据结构类型。
下面是使用这些查询扩展方法的扩展性模型的几个好处:
1) 它允许一个可用于所有数据类型(数据库,XML文件,内存中的对象,以及web-services等)的共同的查询编程模型和语法。
2) 它是可以组合的,允许开发人员轻松地往查询语法中添加新的方法/操作符。譬如,我们可以将我们自定义的“In()”方法与为LINQ所定义的标准的“Where()”方法作为一个单独查询的一部分一起使用。我们自定义的In()方法看上去就跟由System.Linq命名空间提供的标准方法一样。
3) 它是可扩展的,允许与任何数据提供器类型一起使用。譬如,任何一个象NHibernate或LLBLGen这样现有的ORM引擎可以实现LINQ的标准查询操作符来允许对他们现有的ORM实现和映射引擎实现LINQ查询。这允许开发人员学会一个查询数据的共同方式,然后对种类繁多的丰富数据存储实现使用同样的技能。
我将在下几个星期里对LINQ作更多的示范,但想留给你几个例子,这些例子展示了如何对不同类型的数据使用几个内置的LINQ查询扩展方法:
使用场景一:对内存中的.NET对象使用LINQ扩展方法
假定我们象这样定义了代表“Person”的类:
然后我可以使用新的对象初始化器和集合初始化器特性创建和填充一个“people”集合,象这样:
然后我可以使用由System.Linq提供的标准的“Where()”扩展方法来获取这个集合中FirstName的首字符是"S"的那些“Person”对象,象这样:
上面这个新的 p => 语法是“Lambda表达式”的一个例子,是对C# 2.0匿名方法支持的更简明的发展,允许我们通过一个实参来轻松地表达查询过滤(在这个情形下,我们表示我们只想要返回一串firstname属性的首字符是“S”字母的Person对象) 。上面这个查询然后就会返回包含2个对象的序列,Scott 和 Susanne。
我也可以利用由System.Linq提供的新的“Average” 和“Max”扩展方法编写代码来决定我的集合里的人的平均年龄,以及年龄最大的人,象这样:
使用场景二:对XML文件使用LINQ扩展方法
你手工在内存里创建一个硬写(hard-coded)的数据集合大概是很少见的。更有可能的是,你会从一个XM文件,数据库,或web服务里获取数据。
假定我们在硬盘上有一个XML文件,包含下面这样的数据:
很明显地,我可以使用现有的 System.Xml APIs 来装载这个XML文件进一个DOM,然后访问它,或者使用一个层次较低的XmlReader API ,自己对之手工分析。或者,在 Orcas中,我现在也可以使用支持标准的LINQ扩展方法的System.Xml.Linq 实现(即 XLINQ),更优雅地分析和处理XML。
下面的代码例子展示了如何使用LINQ来获取所有包含一个子节点的值的首字母为“S”的<person> XML元素:
注意,它使用了跟内存中对象例子中一模一样的 Where() 扩展方法。现在它返回一个“XElement”元素序列,XElemen是没有类型的XML节点元素。或者我也可以重写查询表达式,通过LINQ的 Select() 扩展方法来构造数据形状,提供一个使用了新的对象初始化器句法的Lambda 表达式来填充同样的“Person”类,跟我们第一个内存中的集合的例子一样:
上面的代码会做需要打开,分析,和过滤XML,然后返回一个强类型的Person对象序列所有的工作,不需要什么映射或持久的文件来映射数值,我只是在上面的LINQ查询式里直接指明了从XML到对象的构形而已。
我也可以和前面一样使用同样的Average() 和 Max() LINQ扩展方法来计算XML文件中<person>元素的平均年龄,以及最大年龄,象这样:
我不用手工分析XML文件,XLINQ 不仅可以为我处理分析,它在估算LINQ表达式时,也可以使用低层的XMLReader,而不是使用DOM来分析文件。这意味着它是迅速之极,而且不分配很多内存。
使用场景三:对数据库使用LINQ扩展方法
假定我们拥有一个SQL数据库,内含一个叫“People”的表,具有下列数据定义:
我可以使用Visual Studio中新的LINQ到SQL的所见即所得(WYSIWYG) ORM设计器,快速地创建一个映射到数据库的“Person”类:
然后我可以使用我先前用于对象和XML文件同样的LINQ Where() 扩展方法,从数据库中获取firstname的首字符为“S”的强类型“Person”对象序列:
注意,查询句法与对象和XML场景中的一模一样。
然后我也可以使用与前面一样的 LINQ Average() 和Max() 扩展方法来从数据库里获取平均和最大值,象这样:
要使上面代码例子工作,你自己不需编写任何SQL代码。Orcas中提供的LINQ到SQL对象关系映射器会处理获取,跟踪,和更新映射到你的数据库数据定义和存储过程的对象。你只要使用任何LINQ扩展方法对结果进行过滤和构形即可,LINQ到SQL会执行获取数据所需的SQL代码(注意,上面的 Average和Max 扩展方法很明显地不会从数据表中返回所有的数据行,它们会使用TSQL的聚合函数来计算数据库中的值,然后只返回一个标量值)。
请观看我一月份制作的一个录像,演示了LINQ到SQL如何显著地改进了Orcas中的数据生产力。录像中,你也可以看到新的LINQ到SQL的所见即所得ORM设计器的实战示范,以及对数据模型编写LINQ代码时代码编辑器提供的完整的 intellisense。
结语
希望上面的帖子给了你一个对扩展方法工作原理的基本理解,以及你能够利用它们来实现的一些酷扩展性方式。跟任何扩展性机制一样,我要告诫你别一开始就滥建新的扩展方法。不能因为你有一个闪亮的新榔头,就意味着世界上所有的东西突然都变成钉子了!
想着手开始尝试扩展方法的话,我建议你先探究一下Orcas中System.Linq命名空间中提供的标准查询操作符。这些操作符提供了对任何数组,集合,XML流,或关系数据库做丰富的查询的支持,可以极大地改进你操作数据时的生产力。我认为你会发现它们极大地减小了你要在你应用中编写的代码量,允许你编写非常干净和描述性强的语句。它们也允许你在你编码中得到查询逻辑自动的intellisense 和编译时检查。
在下几个星期里,我将继续这个关于Orcas中新语言特性的系列,探讨匿名类和类的推断(Type Inference),还会讨论Lambda的细节和其他酷特性。很明显地,我还会地更多地讨论LINQ。
希望本文对你有所帮助,
Scott
什么是Lambda表达式?
随VS 2005发布的C#2.0引进了匿名方法的概念,允许在预期代理(delegate)值的地方用“行内(in-line)”代码块(code blocks)来做替代。
Lambda表达式为编写匿名方法提供了更简明的函数式的句法,但结果却在编写LINQ查询表达式时变得极其有用,因为它们提供了一个非常紧凑的而且类安全的方式来编写可以当作参数来传递,在以后作运算的函数。
Lambda表达式的例子:
在我以前的扩展方法博客贴子里,我演示了你如何可以象下面这样声明一个简单的Person类:
然后,我示范了你可以如何使用一些值来生成一个List<Person>集合的实例,然后使用由LINQ提供的新的Where和Average扩展方法来返回集合中的人的一个子集,以及计算这个集合中的人的平均年龄:
上面高亮标记的红色 p => 表达式就是Lambda表达式。在上面的例子里,我用第一个lambda来指定获取特定人时所用的过滤条件,用第二个lambda来指定在计算平均年龄时该用Person对象的哪个值。
详解Lambda表达式
理解Lambda表达式最容易的方法是把它们设想成编写简明的行内方法的方式。譬如,我上面编写的例子可以使用C#2.0的匿名方法来编写,象这样:
上面两个匿名方法都接受一个Person类型的参数。第一个匿名方法返回一个布尔值,表示Person的LastName是否是Guthrie,第二个匿名方法返回一个整数值(返回那个人的年龄)。我们前面使用的lambda表达式的作用是一样的,两个表达式都接受一个Person类型的参数。第一个lambda表达式返回一个布尔值,第二个返回一个整数。
在C#里,一个lambda表达式在句法上是写成一个参数列表,随后是 => 符号,随后是表达式在调用时要运算的表达式或者语句块:
params => expression
所以,当我们编写这样的lambda表达式时:
p => p.LastName == "Guthrie"
我们是想表示,我们在定义的Lambda接受一个参数p,要运行的代码表达式返回p.LastName的值是否等于“Guthrie”。 我们将参数命名为p是不相干的,我也可以很容易地将其命名为o,x,foo,或者我想要的任何名字。
不象匿名方法要求参数类型是明确地指明的,Lambda表达式允许省略参数类型,而允许它们根据用法来推断出类型。譬如,当我编写 p=>p.LastName == "Guthrie" 这个lambda表达式时,编译器推断出p参数属于Person类型,因为当前的Where扩展方法的对象是个范型的List<Person>集合。
Lambda参数的类型可以在编译时和被Visual Studio的intellisense引擎推断出来,这意味着在编写lambda时你将获得完全的intellisense 和编译时检查。譬如,注意当我在下面健入 p. 时,Visual Studio Orcas是如何提供intellisense完成的,因为它知道 p 是 Person类型:
注: 假如你要给一个Lambda表达式明确地声明参数的类型的话,你可以在Lambda参数表里的参数名字前声明参数类型,象这样:
针对框架开发人员的高级内容:Lambda表达式树 (Lambda Expression Trees)
从一个框架开发人员(framework developer)的角度来看,使得Lambda表达式特别强有力的事情之一是,它们既可以以基于IL的方法的形式被编译成代码代理(code delegate),或者也可以编译成一个表达式树(expression tree)对象,然后在运行时用来分析,转换或者优化表达式。
能将Lambda表达式编译成一个表达式树对象是个强大无比的机制,将促成许多使用场景,包括使用能提供编译时句法检查和VS intellisense的统一的查询语言来建立支持丰富数据查询的高性能对象映射器(无论是关系数据库,活动目录,还是web服务)之能力。
从Lambda表达式到代码代理 (Code Delegates)
上面的Where扩展方法是个将Lambda表达式编译成代码代理(code delegate)的例子(意即它是编译成IL的,可以以代理的形式调用)。支持象上面那样过滤任何IEnumerable集合的Where()扩展方法可以使用下面这样的扩展方法代码来实现:
上面的Where()扩展方法接受一个 Func<T, bool> 类型的过滤参数,该参数是个接受一个类型为T的参数,返回一个布尔值表示条件是否满足的方法之代理。当我们把Lambda表达式作为一个参数传递给这个Where() 扩展方法时,C#编译器会将我们的Lambda表达式编译成IL方法代理(这里,<T> 将是Person),然后我们的Where()方法可以调用来计算某个给定条件是否被满足了。
从Lambda表达式到表达式树
当我们要想针对类似我们的列表集合一样的内存中的数据做运算时,把lambda表达式编译成代码代理是恰如其分的。但考虑一下你想要查询数据库里的数据的情形(下面的代码是使用Orcas中内置的LINQ到SQL对象关系映射器写成的) :
这里,我要从数据库里取出一串强类型的Product对象,我向Where()扩展方法表示,要通过一个Lambda表达式来做过滤。
我绝对不想要看到发生的是,从数据库里取回所有的产品记录,将它们放在一个局部的集合里,然后在内存里对它运行Where()扩展方法来进行过滤。这么做效率极其不高,对大数据库的扩缩性将是极差的。而我希望的是,LINQ到SQL的ORM将我上面的Lambda过滤条件翻译成SQL表达式,然后在远程的数据库里进行过滤性查询。那样的话,我只返回那些符合查询条件的记录,这样的数据库查询效率是非常高的。
框架开发人员可以通过声明他们的Lambda表达式参数是个Expression<T>类型,而不是Func<T>类型来取得这样的结果。这会导致Lambda表达式参数被编译成一个我们可以在运行时拆开和分析的表达式树:
注意上面我是怎么把我们在先前用过的同样的 p=>p.LastName == "Guthrie" Lambda表达式,但这次将其赋值给一个 Expression<Func<Person, bool>> 变量,而不是Func<Person,bool> 变量。编译器不会产生IL,而是会指派一个表达式树对象,然后我作为一个框架开发人员就可以用它来对相应的Lambda表达式进行分析,按我想要的方式对其进行运算(譬如,我可以挑出表达式中的类型,名字和值等)。
在LINQ到SQL的情形下,它会将这个Lambda过滤语句翻译成标准的关系SQL语句,来对数据库进行操作(从逻辑上来说,一个“SELECT * from Products where UnitPrice < 55”语句)。
IQueryable<T> 接口
为帮助框架开发人员建立可查询的数据提供器,LINQ提供了 IQueryable<T> 接口。这个接口实现了标准的LINQ扩展方法查询运算符,提供了一个更便利的方式来实现对一个复杂的表达式树的处理(譬如,象下面这样,我用了3个不同的扩展方法,2个lambda来从数据库取回10个产品的情形):
想阅读一些关于如何使用 IQueryable<T> 来建立自定义的LINQ数据提供器的精彩博客系列的话,请看一下下面这些别人写的精彩博客贴子:
- LINQ to Amazon: Part 1, Part 2, Part 3
- LINQ to NHibernate: Part 1, Part 2, Part 3
- LINQ to LDAP: Part 1, Part 2, Part 3, Part 4
结语
希望上面的贴子内容对如何考虑和使用Lambda表达式提供了基本的理解。当与Orcas中System.Linq命名空间下提供的内置标准查询扩展方法结合使用时,它们提供了一个非常好的方式来对任何类型的数据进行查询和交互,同时还保持了对完整的编译时检查和intellisense的支持。
通过利用由Lambda提供的对表达式树的支持,以及 IQueryable<T> 接口,构建数据提供器的框架开发人员可以确保开发人员编写的干净的编码,对任何数据源(无论是数据库,XML文件,内存中的对象,web服务,LDAP系统等)运行起来速度快而且效率高。
在下几个星期里,我将完成这个从理论的层次上讨论新核心语言概念的语言系列,然后转到讨论一些极其实用的实战例子(特别是针对数据库和XML文件使用LINQ的场景)。
希望本文对你有所帮助