扩展方法中的lambda何时做得太多？

Question

我意识到这是部分主观的,但我一般好奇,社区的意见,并没有能够成功找到一个存在的问题是铲球这个问题.

我与同事就L2EF查询中的特定Select语句进行了一些宗教辩论.

.Select(r =>
{
    r.foo.Bar = r.bar;
    r.foo.Bar.BarType = r.Alpha;
    if (r.barAddress != null)
    {
        r.foo.Bar.Address = r.barAddress;
        r.foo.Bar.Address.State = r.BarState;
    }
    if (r.baz != null)
    {
        r.foo.Bar.Baz = r.baz;
        if (r.bazAddress != null)
        {
            r.foo.Bar.Baz.Address = r.bazAddress;
            r.foo.Bar.Baz.Address.State = r.BazState;
        }
    }
    return r.foo;
})

注意事项:

• 这是Linq-to-Entities
• 这是在执行并返回DB中的工作之后
• 输入参数r是匿名的

就个人而言,我认为(a)选择条款不应该改变价值,它应该只是投射.他相反的观点是,他并没有改变什么,他只是确保一切正确初始化为DB查询的结果.其次,我认为一旦他开始进入完整的代码块和返回语句,它的时间来定义一个方法,甚至是Func<T, U>不要做这一切的内联.这里的复合器同样是输入是匿名的,因此需要定义一个类型.但是,尽管如此,我们仍在辩论一般性观点.

那么,lambda表达式什么时候做的太多了？你在哪里画出沙子中的模糊线？

Answer 1

我的第一直觉是同意你的观点，主要是在规模和复杂性方面。

然而，它在将（或有时）作为 .NET 代码以外的其他内容执行的上下文中使用（特别是如果它变成 SQL 查询的一部分），我会变得更加容忍它。

所以，这就是我画模糊线的地方，也是我再次移动它的原因:)