问 使用EF6优化LINQ查询

EN

对于简单实体，即不引用其他实体(导航属性)的实体，您的方法本质上是很好的。它可以浓缩成：

public static List<Table1> GetAllDatainTable()
    using (var context = new EFContext())
       return context.Table1s.ToList();
}

然而，在大多数真实世界的场景中，您将希望将导航属性之类的东西用于实体之间的关系。例如，订单使用地址详细信息引用客户，并包含OrderLines，每个客户都引用产品等。以这种方式返回实体会出现问题，因为接受这种方法返回的实体的任何代码都应该是完整的，或者是可完成的实体。

例如，如果我有一个返回订单的方法，并且有各种使用订单信息的代码:其中一些代码可能试图获取有关订单客户的信息，其他代码可能对这些产品感兴趣。EF支持延迟加载，以便相关数据可以在需要时被提取，但是这只能在DbContext的生命周期内工作。像这样的方法处理DbContext，所以延迟加载是不可能的。

一种选择是急切地加载所有内容：

using (var context = new EFContext())
    var order = context.Orders
        .Include(o => o.Customer)
            .ThenInclude(c => c.Addresses)
        .Include(o => o.OrderLines)
            .ThenInclude(ol => ol.Product)
        .Single(o => o.OrderId == orderId);
    return order;
}

然而，这种方法有两个缺点。首先，这意味着每次获取订单时都要加载更多的数据 。消费代码可能并不关心客户或订单行，但我们已经加载了所有这些代码。其次，随着系统的发展，可能会引入新的关系，即当包含越来越多的相关数据时，不一定会注意到更新旧代码以包括可能导致的 NullReferenceException 、bug或性能问题。视图或其他最初使用该实体的东西可能不会期望引用这些新关系，但是一旦您开始将实体传递到视图、视图和其他方法，任何接受实体的代码都应该期望依赖于实体是完整的或可以使其完整这一事实。如果命令可能加载在不同级别的“完整性”和处理数据是否加载的代码中，这可能是一场噩梦。作为一般性建议，我建议不要在加载实体的DbContext范围之外传递实体。

更好的解决方案是利用投影从适合代码消耗的实体中填充视图模型。WPF通常使用MVVM模式，因此这意味着使用EF的 Select 方法或Automapper的 ProjectTo 方法来填充基于每个使用者需求的视图模型。当您的代码使用包含数据视图和此类需求的ViewModels时，然后根据需要加载和填充实体，这将使您能够产生更高效(快速)和弹性更强的查询来获取数据。

如果我有一个视图，该视图列出具有创建日期、客户名称和产品/w数量列表的订单，那么我们为视图定义一个视图模型：

[Serializable]
public class OrderSummary
    public int OrderId { get; set; }
    public string OrderNumber { get; set; }
    public DateTime CreatedAt { get; set; }
    public string CustomerName { get; set; }
    public ICollection<OrderLineSummary> OrderLines { get; set; } = new List<OrderLineSummary>();
[Serializable]
public class OrderLineSummary
    public int OrderLineId { get; set; }
    public int ProductId { get; set; }
    public string ProductName { get; set; }
    public int Quantity { get; set; }
}

然后在Linq查询中投影视图模型：

using (var context = new EFContext())
    var orders = context.Orders
        // add filters & such /w Where() / OrderBy() etc.
        .Select(o => new OrderSummary
            OrderId = o.OrderId,
            OrderNumber = o.OrderNumber,
            CreatedAt = o.CreatedAt,
            CustomerName = o.Customer.Name,
            OrderLines = o.OrderLines.Select( ol => new OrderLineSummary
                OrderLineId = ol.OrderLineId,
                ProductId = ol.Product.ProductId,
                ProductName = ol.Product.Name,
                Quantity = ol.Quantity
            }).ToList()
        }).ToList();
    return orders;
}

请注意，我们不需要担心急切地加载相关实体，而且如果以后订单或客户或这样的客户获得新的关系，那么上面的查询将继续工作，只有在新的关系信息对其服务的视图有用的情况下才会进行更新。它可以组成一个速度更快、内存更少的查询，获取更少的字段，以便从数据库传递到应用程序，并且可以使用索引来进一步调优这一点，以适应高使用的查询。

更新：

附加性能提示:通常避免使用像 GetAll*() 这样的方法作为最低的公共分母方法。我在这种方法中遇到的性能问题太多了，它们的形式是：

var ordersToShip = GetAllOrders()
    .Where(o => o.OrderStatus == OrderStatus.Pending)
    .ToList();
foreach(order in ordersToShip)
    // do something that only needs order.OrderId.
}

其中 GetAllOrders() 返回 List<Order> 或 IEnumerable<Order> 。有时会有类似于 GetAllOrders().Count() > 0 之类的代码。

这样的代码效率极低，因为 GetAllOrders() 从数据库中获取*所有记录，只是将它们加载到应用程序中的内存中，以便稍后被过滤或计数等等。

如果您遵循一条通过方法将EF DbContext和实体抽象到服务/存储库中的路径，那么您应该确保服务公开方法以产生有效的查询，或者放弃抽象，并在需要数据的地方直接利用DbContext。

var orderIdsToShip = context.Orders
    .Where(o => o.OrderStatus == OrderStatus.Pending)
    .Select(o => o.OrderId)
    .ToList();