常见误区 #4: 使用迭代式 (而不是声明式)的语句去操作集合 在C# 3.0中，LINQ的引入改变了我们以往对集合对象的查询和修改操作。从这以后，你应该用LINQ去操作集合，而不是通过迭代的方式。 一些C#的程序员甚至都不知道LINQ的存在，好在不知道的人正在逐步减少。但是还有些人误以为LINQ只用在数据库查询中，因为LINQ的关键字和SQL语句实在是太像了。 虽然数据库的查询操作是LINQ的一个非常典型的应用，但是它同样可以应用于各种可枚举的集合对象。（如：任何实现了IEnumerable接口的对象）。举例来说，如果你有一个Account类型的数组，不要写成下面这样： decimal total = 0; foreach (Account account in myAccounts) { if (account.Status == "active") {
total += account.Balance;
}
}你只要这样写： decimal total = (from account in myAccounts where account.Status == "active" select account.Balance).Sum(); 虽然这是一个很简单的例子，在有些情况下，一个单一的LINQ语句可以轻易地替换掉你代码中一个迭代循环（或嵌套循环）里的几十条语句。更少的代码通常意味着产生Bug的机会也会更少地被引入。然而，记住，在性能方面可能要权衡一下。在性能很关键的场景，尤其是你的迭代代码能够对你的集合进行假设时，LINQ做不到，所以一定要在这两种方法之间比较一下性能。 #5常见错误：在LINQ语句之中没有考虑底层对象对于处理抽象操纵集合任务，LINQ无疑是庞大的。无论他们是在内存的对象，数据库表，或者XML文档。在如此一个完美世界之中，你不需要知道底层对象。然而在这儿的错误是假设我们生活在一个完美世界之中。事实上，相同的LINQ语句能返回不同的结果，当在精确的相同数据上执行时，如果该数据碰巧在一个不同的格式之中。 例如，请考虑下面的语句：
想象一下，该对象之一的账号会发生什么。状态等于“有效的”（注意大写A)? 好吧，如果myaccout是Dbset的对象。（默认设置了不同区分大小写的配置），where表达式仍会匹配该元素。然而，如果myaccout是在内存阵列之中，那么它将不匹配，因此将产生不同的总的结果。 等一会，在我们之前讨论过的字符串比较中, 我们看见 == 操作符扮演的角色就是简单的比较. 所以，为什么在这个条件下， == 表现出的是另外的一个形式呢 ? 答案是，当在LINQ语句中的基础对象都引用到SQL表中的数据（如与在这个例子中，在实体框架为DbSet的对象的情况下），该语句被转换成一个T-SQL语句。然后遵循的T-SQL的规则，而不是C＃的规则，所以在上述情况下的比较结束是不区分大小写的。 一般情况下，即使LINQ是一个有益的和一致的方式来查询对象的集合，在现实中你还需要知道你的语句是否会被翻译成什么比C＃的引擎或者是其他表达，来确保您的代码的行为将如预期在运行时。 常见错误 #6：对扩展方法感到困惑或者被它的形式欺骗如同先前提到的，LINQ状态依赖于IEnumerable接口的实现对象，比如，下面的简单函数会合计帐户集合中的帐户余额： public decimal SumAccounts(IEnumerable<Account> myAccounts) { return myAccounts.Sum(a => a.Balance);
}在上面的代码中，myAccounts参数的类型被声明为IEnumerable<Account>，myAccounts引用了一个Sum 方法 (C# 使用类似的 “dot notation” 引用方法或者接口中的类),我们期望在IEnumerable<T>接口中定义一个Sum()方法。但是，IEnumerable<T>没有为Sum方法提供任何引用并且只有如下所示的简洁定义： public interface IEnumerable<out T> : IEnumerable {
IEnumerator<T> GetEnumerator();
}但是Sum方法应该定义到何处？C#是强类型的语言，因此如果Sum方法的引用是无效的，C#编译器会对其报错。我们知道它必须存在，但是应该在哪里呢？此外，LINQ提供的供查询和聚集结果所有方法在哪里定义呢？ 答案是Sum并不在IEnumerable接口内定义，而是一个 定义在System.Linq.Enumerable类中的static方法（叫做“extension method”） namespace System.Linq {
public static class Enumerable { ...
// the reference here to “this IEnumerable<TSource> source” is
// the magic sauce that provides access to the extension method Sum
public static decimal Sum<TSource>(this IEnumerable<TSource> source,
Func<TSource, decimal> selector); ...
}
}可是扩展方法和其它静态方法有什么不同之处，是什么确保我们可以在其它类访问它？ 扩展方法的显著特点是第一个形参前的this修饰符。这就是编译器知道它是一个扩展方法的“奥妙”。它所修饰的参数的类型（这个例子中的IEnumerable<TSource>）说明这个类或者接口将显得实现了这个方法。 （另外需要指出的是，定义扩展方法的IEnumerable接口和Enumerable类的名字间的相似性没什么奇怪的。这种相似性只是随意的风格选择。） 理解了这一点，我们可以看到上面介绍的sumAccounts方法能以下面的方式实现： public decimal SumAccounts(IEnumerable<Account> myAccounts) {
return Enumerable.Sum(myAccounts, a => a.Balance);
}事实上我们可能已经这样实现了这个方法，而不是问什么要有扩展方法。扩展方法本身只是C#的一个方便你无需继承、重新编译或者修改原始代码就可以给已存的在类型“添加”方法的方式。 扩展方法通过在文件开头添加using [namespace];引入到作用域。你需要知道你要找的扩展方法所在的名字空间。如果你知道你要找的是什么，这点很容易。 当C#编译器碰到一个对象的实例调用了一个方法，并且它在这个对象的类中找不到那个方法，它就会尝试在作用域中所有的扩展方法里找一个匹配所要求的类和方法签名的。如果找到了，它就把实例的引用当做第一个参数传给那个扩展方法，然后如果有其它参数的话，再把它们依次传入扩展方法。（如果C#编译器没有在作用域中找到相应的扩展方法，它会抛措。） 对C#编译器来说，扩展方法是个“语法糖”，使我们能把代码写得更清晰，更易于维护（多数情况下）。显然，前提是你知道它的用法，否则，它会比较容易让人迷惑，尤其是一开始。 应用扩展方法确实有优势，但也会让那些对它不了解或者认识不正确的开发者头疼，浪费时间。尤其是在看在线示例代码，或者其它已经写好的代码的时候。当这些代码产生编译错误（因为它调用了那些显然没在被调用类型中定义的方法），一般的倾向是考虑代码是否应用于所引用类库的其它版本，甚至是不同的类库。很多时间会被花在找新版本，或者被认为“丢失”的类库上。 在扩展方法的名字和类中定义的方法的名字一样，只是在方法签名上有微小差异的时候，甚至那些熟悉扩展方法的开发者也偶尔犯上面的错误。很多时间会被花在寻找“不存在”的拼写错误上。 在C#中，用扩展方法变得越来越流行。除了LINQ，在另外两个出自微软现在被广泛使用的类库Unity Application Block和Web API framework中，也应用了扩展方法，而且还有很多其它的。框架越新，用扩展方法的可能性越大。 当然，你也可以写你自己的扩展方法。但是必须意识到虽然扩展方法看上去和其它实例方法一样被调用，但这实际只是幻。事实上，扩展方法不能访问所扩展类的私有和保护成员，所以它不能被当做传统继承的替代品。 |
