创建 LINQ 查询内联委托实例的效率？

Question

以下是以不同方式执行同一操作的两个示例。我正在比较它们。

版本 1

作为示例，定义任何方法来根据业务逻辑从 XElement 创建并返回 ExpandoObject：

var ToExpando = new Func<XElement, ExpandoObject>(xClient =>
{
    dynamic o = new ExpandoObject();    
    o.OnlineDetails = new ExpandoObject();
    o.OnlineDetails.Password = xClient.Element(XKey.onlineDetails).Element(XKey.password).Value;
    o.OnlineDetails.Roles = xClient.Element(XKey.onlineDetails).Element(XKey.roles).Elements(XKey.roleId).Select(xroleid => xroleid.Value);
    // More fields TBD.
}

从 LINQ to XML 查询调用上述委托：

var qClients =
    from client in xdoc.Root.Element(XKey.clients).Elements(XKey.client)
    select ToExpando(client);

---

版本 2

在 LINQ 查询中完成所有操作，包括创建和调用 Func 委托。

var qClients =
from client in xdoc.Root.Element(XKey.clients).Elements(XKey.client)
select (new Func<ExpandoObject>(() =>
        {
            dynamic o = new ExpandoObject();
            o.OnlineDetails = new ExpandoObject();
            o.OnlineDetails.Password = client.Element(XKey.onlineDetails).Element(XKey.password).Value;
            o.OnlineDetails.Roles = client.Element(XKey.onlineDetails).Element(XKey.roles).Elements(XKey.roleId).Select(xroleid => xroleid.Value);
            // More fields TBD.
  return o;
  }))();

---

考虑到委托创建是在 select 部分中进行的，版本 2 是否效率低下？它是否由 C# 编译器或运行时管理或优化，因此并不重要？

我喜欢版本 2，因为它的紧密性（在查询中保留对象创建逻辑），但我知道它可能不可行，具体取决于关于编译器或运行时的作用。

Answer 1

后一种方法对我来说看起来非常可怕。我相信每次捕获不同的客户端时都必须真正创建一个新的委托，但我个人根本不会这样做。既然你已经有了真正的语句，为什么不写一个普通的方法呢？

private static ToExpando(XElement client)
{
    // Possibly use an object initializer instead?
    dynamic o = new ExpandoObject();    
    o.OnlineDetails = new ExpandoObject();
    o.OnlineDetails.Password = client.Element(XKey.onlineDetails)
                                     .Element(XKey.password).Value;
    o.OnlineDetails.Roles = client.Element(XKey.onlineDetails)
                                  .Element(XKey.roles)
                                  .Elements(XKey.roleId)
                                  .Select(xroleid => xroleid.Value);
    return o;
}

然后查询它：

var qClients = xdoc.Root.Element(XKey.clients)
                        .Elements(XKey.client)
                        .Select(ToExpando);

我会更更关心代码的可读性而不是创建委托的性能，这通常很快。我认为没有必要像您目前所希望的那样使用尽可能多的 lambda。想象一下一年后您何时再次查看这段代码。您真的会发现嵌套 lambda 比方法更容易理解吗？

（顺便说一句，将转换逻辑分离到一个方法中可以轻松地进行单独测试...）

编辑：即使您确实想要在 LINQ 表达式中完成所有操作，为什么这么想热衷于创建另一个间接级别？仅仅因为查询表达式不允许语句 lambda？鉴于您只是进行简单的选择，因此很容易处理：

var qClients = xdoc.Root
           .Element(XKey.clients)
           .Elements(XKey.client)
           .Select(client => {
               dynamic o = new ExpandoObject();
               o.OnlineDetails = new ExpandoObject();
               o.OnlineDetails.Password = client.Element(XKey.onlineDetails)
                                                .Element(XKey.password).Value;
               o.OnlineDetails.Roles = client.Element(XKey.onlineDetails)
                                             .Element(XKey.roles)
                                             .Elements(XKey.roleId)
                                             .Select(xroleid => xroleid.Value);
               return o; 
           });

Answer 2

确实，您的第二个版本会重复创建新的 Func 实例 - 但是，这仅意味着分配一些小对象（闭包）并使用指向函数的指针。与您需要在委托主体中执行的动态查找（使用动态对象）相比，我认为这并不是一个很大的开销。

或者，您可以像这样声明一个本地 lambda 函数：

Func<XElement, ExpandoObject> convert = client => {
    dynamic o = new ExpandoObject();
    o.OnlineDetails = new ExpandoObject();
    o.OnlineDetails.Password = 
       client.Element(XKey.onlineDetails).Element(XKey.password).Value;
    o.OnlineDetails.Roles = client.Element(XKey.onlineDetails).
       Element(XKey.roles).Elements(XKey.roleId).
       Select(xroleid => xroleid.Value);
    // More fields TBD.
    return o;
}

var qClients =
    from client in xdoc.Root.Element(XKey.clients).Elements(XKey.client)
    select convert(client);

这样，您可以只创建一个委托，但将执行转换的代码保持在靠近实现查询的代码的位置。

另一种选择是使用匿名类型 - 在您的场景中使用ExpandoObject 的原因是什么？匿名类型的唯一限制是您可能无法从其他程序集访问它们（它们是内部的），但使用动态处理它们应该没问题。 ..

您的选择可能如下所示：

select new { OnlineDetails = new { Password = ..., Roles = ... }}

最后，您还可以使用反射将匿名类型转换为 ExpandoObject，但这可能会更加低效（即很难高效编写）