支持详细Linq表达式

本文关键字：表达式 Linq 支持 | 更新日期: 2023-09-27 18:01:41

我突然想到，我以一种简单的方式写出linq语句，但其他人可能会认为这是冗长的方式;

一个简单的例子:

return _entries
    .Where(x => x.Context.Equals(context))
    .Where(x => x.Type == typeof (T))
    .Select(x=>x.Value)
    .Cast<T>()
    .Single();

可以简化为:

return _entries
    .Where(x => x.Context.Equals(context) && x.Type == typeof (T))
    .Select(x=>(T)x.Value)
    .Single();
[问题]

从长远来看，哪种是更好的编码实践?即长(和简单)链接链或短链接链更复杂的选择器/等?

假设这些Linq语句将被编译器优化是正确的吗?

支持详细Linq表达式

从长远来看，哪种是更好的编码实践?

我喜欢简短和简单。它更容易读懂。LINQ的全部要点是使代码读起来更像业务领域的逻辑。

假设这些Linq语句将被编译器优化是正确的吗?

没有;优化是由运行时完成的，而不是由编译器完成的。遵循您所描述的模式的LINQ-to-objects"Where"answers"Select"子句在运行时被优化为单个"Where - Select"对象，以避免创建过多的迭代器。(尽管正如乔恩·斯基特(Jon Skeet)所发现的，这有时会导致性能下降;就像几乎所有的"优化"一样，这并不是100%的成功。遗憾的是，我现在找不到Jon关于这方面的文章。

不，假设这些LINQ语句是由编译器优化的是不对的。更详细的语法会产生更多的Enumerator对象，因此两者并不等同。从性能的角度来看，较短的语法会(稍微)更好。

但是，如果您从可读性和编码的角度在两种语法之间进行选择，我会选择第一种语法，因为它更好地显示了所采取的步骤。我总是更喜欢可读性而不是性能，除非你能证明存在性能瓶颈。

但是，有一个OfType<T>() LINQ操作符可能会对您有用。你的第一个例子，重写为:

return _entries
    .Where(x => x.Context.Equals(context))
    .OfType<T>()
    .Select(x => (T)x.Value)
    .Single();

从长远来看，更好的编码实践是更具可读性的。如果您关心性能，那么测试这两种方法。如果它不值得测试，那么它就不值得优化。

我喜欢Linq表达式，因为它提供了一种声明式地表达代码意图的方法。它关注的是你想要实现什么而不是如何实现它。所以要强调代码的可读性。

但是用Linq操作符替换一些for/foreach块也可能使代码难以实现。所以我建议把你的表达式写成冗长的形式，这样你就可以口头地向你的合作程序员描述逻辑，例如下面的表达式可以被描述为"返回一个类型为T的单一值，其中条目context等于context, type等于T"。如果需要，编写自定义扩展方法，如将值强制转换为t类型的As<T>() 

return _entries
    .Where(x => x.Context.Equals(context) && x.Type == typeof (T))
    .Single (x=> x.Value)
    .As<T>();
相关文章：