您会将 LINQ 查询抽象为扩展方法吗

Question

在我当前的项目中，我们为代码指标“可维护性指数”和“循环复杂度”设定了一些目标。可维护性指数应为 60 或更高，圈复杂度应为 25 或更低。我们知道，60 及以上的可维护性指数是相当高的。

我们还使用大量 linq 来过滤/分组/选择实体。我发现这些 linq 查询在可维护性指数上的得分并不高。 将这些查询抽象为扩展方法给了我更高的可维护性指数，这很好。但在大多数情况下，扩展方法不再是通用的，因为我将它们与我的类型而不是通用类型一起使用。

例如，以下 linq-query 与扩展方法：

Linq 查询

List.Where(m => m.BeginTime >= selectionFrom && m.EndTime <= selectionTo)

扩展方法：

public static IEnumerable<MyType> FilterBy(this IEnumerable<MyType> source, DateTime selectionFrom, DateTime selectionTo)
{
    return (IEnumerable<MyType>)source.Where(m => m.BeginTime >= selectionFrom && m.EndTime <= selectionTo);
}

List.FilterBy(selectionFrom, selectionTo);

扩展方法使我的可维护性指数提高了 6 个点，并提供了良好的流畅语法。 另一方面，我必须添加一个静态类，它不是通用的。

关于哪种方法会受到您的青睐有什么想法吗？或者也许对如何重构 linq 查询以提高可维护性指数有不同的想法？

Answer 1

您不应该为了指标而添加类。任何指标都是为了让您的代码更好，但盲目遵循规则，即使是最好的规则，实际上可能会损害您的代码。

我认为坚持某些可维护性和复杂性指标不是一个好主意。我相信它们对于评估旧代码很有用，即当您继承一个项目并需要估计其复杂性时。然而，因为你没有获得足够的分数而提取方法是荒谬的。

只有在重构为代码增加价值的情况下才进行重构。这种价值是一种无法用数字表达的复杂的人类指标，而对其进行估计正是编程体验的意义所在——在两者之间找到平衡优化vs可读性vs干净的APIvs酷代码vs简单代码vs快速发货对比泛化与规范等。

这是您应该遵循的唯一指标，但它并不总是每个人都同意的指标...

至于您的示例，如果一遍又一遍地使用相同的 LINQ 查询，它在 Extensions 文件夹中创建一个 EnumerableExtensions 并将其提取到那里是非常有意义的。但是，如果它使用一次或两次，或者可能会发生变化，则详细查询要好得多。

我也不明白为什么你说它们不是通用的，带有一些负面含义。你不需要到处都是泛型！事实上，在编写扩展方法时，您应该考虑可以选择的最具体的类型，以免污染其他类的方法集。如果您希望帮助程序仅使用 IEnumerable，那么为 this IEnumerable 声明一个扩展方法绝对没有什么可耻的。顺便说一下，您的示例中有多余的转换。摆脱它。

不要忘记，工具是愚蠢的。我们人类也是如此。

Answer 2

我给您的建议是...不要成为指标的奴隶！它们是机器生成的，仅用作指导。他们永远无法取代熟练且经验丰富的程序员。

您认为哪一个最适合您的应用程序？

Answer 3

我个人同意扩展方法策略。我在一些实际应用程序中使用它没有出现任何问题。

对我来说，这不仅与指标有关，还与代码的可重用性有关。请参阅以下伪示例：

var x = _repository.Customers().WhichAreGoldCustomers();

var y = _repository.Customers().WhichAreBehindInPayments();

使用这两种扩展方法可以实现您的指标目标，并且它还提供“一个定义黄金客户的地方”。当不同的开发人员需要与“黄金客户”合作时，您不会在不同的地方创建不同的查询。

此外，它们是可组合的：

var z = _repository.Customers().WhichAreGoldCustomers().WhichAreBehindInPayments();

恕我直言，这是一种成功的方法。

我们面临的唯一问题是 ReSharper 存在一个错误，有时扩展方法的智能感知会变得疯狂。您键入“.Whic”，它可以让您选择所需的扩展方法，但是当您在其上“选项卡”时，它会在代码中放入完全不同的内容，而不是您选择的扩展方法。为此，我考虑过从 ReSharper 切换过来，但是……不:)

Answer 4

不：在这种情况下，我会忽略圈复杂度 - 你最初拥有的更好。

问问自己什么更能解释。这个：

List.Where(m => m.BeginTime >= selectionFrom && m.EndTime <= selectionTo)

或者这个：

List.FilterBy(selectionFrom, selectionTo);

第一个清楚地表达了你想要的东西，而第二个则没有。了解“FilterBy”含义的唯一方法是进入源代码并查看其实现。

将查询片段抽象为扩展方法对于更复杂的场景来说是有意义的，在这些场景中，很难一眼判断查询片段正在做什么。

Answer 5

我已经在一些地方使用了这种技术，例如，一个 Payment 类有一个相应的 PaymentLinqExtensions 类，它为 Payments 提供了特定于域的扩展。

在您给出的示例中，我将选择一个更具描述性的方法名称。还有一个问题是范围是包含还是排除，否则看起来还可以。

如果您的系统中有多个对象，其中日期的概念很常见，那么请考虑一个接口，也许是 IHaveADate （或更好的东西:-)

public static IQueryable<T> WithinDateRange(this IQueryable<T> source, DateTime from, DateTime to) where T:IHaveADate

（IQueryable 很有趣。我不认为 IEnumerable 可以转换为它，这是一个遗憾的是，如果您正在使用数据库查询，那么它可以让您的逻辑出现在发送到服务器的最终 SQL 中，这很好，所有 LINQ 都存在一个潜在问题，即您的代码不会在您期望的时候执行。是）

如果日期范围是应用程序中的一个重要概念，并且您需要在该范围是从“EndDate”结束时的午夜开始还是在其开始时的午夜开始方面保持一致，那么 DateRange 类可能会很有用。然后

public static IQueryable<T> WithinDateRange(this IQueryable<T> source, DateRange range) where T:IHaveADate

，如果您愿意，您也可以提供，

public static IEnumerable<T> WithinDateRange(this IEnumerable<T> source, DateRange range, Func<DateTime,T> getDate)

但这对我来说感觉更多与 DateRange 有关。我不知道它会使用多少，尽管您的情况可能会有所不同。我发现过于通用会使事情变得难以理解，并且 LINQ 也很难调试。

var filtered = myThingCollection.WithinDateRange(myDateRange, x => x.Date)