LINQ 使用 EF6 进行查询优化

Question

我第一次尝试 LINQ 并且只是想发布一个小问题以确保这是否是 go 关于它的最佳方式。 我想要一个表中每个值的列表。 到目前为止，这就是我所拥有的，并且它有效，但这是 go 关于以 LINQ 友好的方式收集所有内容的最佳方式吗？

    public static List<Table1> GetAllDatainTable()
    {
        List<Table1> Alldata = new List<Table1>();

        using (var context = new EFContext())
        {
           Alldata = context.Tablename.ToList();
        }
        return Alldata;
    }

Answer 1

对于简单实体，即没有引用其他实体（导航属性）的实体，您的方法基本上没问题。 它可以浓缩为：

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

但是，在大多数实际场景中，您将希望利用导航属性之类的东西来建立实体之间的关系。 即，订单引用具有地址详细信息的客户，并包含每个都引用产品等的订单行。以这种方式返回实体会出现问题，因为任何接受此类方法返回的实体的代码都应该是完整的或可完成的实体。

例如，如果我有一个返回订单的方法，并且我有各种使用该订单信息的代码：其中一些代码可能会尝试获取有关订单客户的信息，而其他代码可能对产品感兴趣。 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 、错误或性能问题。 视图或最初使用该实体的任何东西可能不希望引用这些新关系，但是一旦您开始将实体传递给视图、视图和其他方法，任何接受实体的代码都应该期望依赖于以下事实：实体是完整的或可以完成的。 无论是否加载数据，都可能以不同级别的“完整性”和代码处理加载订单，这可能是一场噩梦。 作为一般建议，我建议不要在加载它们的 DbContext 的 scope 之外传递实体。

更好的解决方案是利用投影从适合您的代码使用的实体中填充视图模型。 WPF 经常使用 MVVM 模式，因此这意味着使用 EF 的Select方法或 Automapper 的ProjectTo方法来根据每个消费者的需求填充视图模型。 当您的代码使用包含数据视图和此类需求的 ViewModel 时，然后根据需要加载和填充实体，这允许您生成更高效（快速）和弹性查询来获取数据。

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

[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;
}

请注意，我们不需要担心急切加载相关实体，如果以后有订单或客户或此类获得新关系，上述查询将继续工作，只有在新关系信息对以下内容有用时才会更新它服务的视图。 它可以组成一个更快、更少的 memory 密集型查询，获取更少的字段以通过网络从数据库传递到应用程序，并且可以使用索引来进一步调整它以用于高使用查询。

更新：

其他性能提示：通常避免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()从数据库中获取 *所有记录，只是将它们加载到应用程序中的 memory 中，以便稍后过滤或计数等。

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

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


var customerOrderCount = context.Customer
    .Where(c => c.CustomerId == customerId)
    .Select(c => c.Orders.Count())
    .Single();

EF is extremely powerful and when selected to service your application should be embraced as part of the application to give the maximum benefit. 我建议避免编码以纯粹为了抽象而将其抽象出来，除非您希望使用单元测试来隔离对数据的依赖与模拟。 在这种情况下，我建议利用 DbContext 的工作单元包装器和利用IQueryable的存储库模式来简化隔离业务逻辑。