实体框架 - Linq 中的数据库视图或连接到实体答案

【问题标题】：Entity Framework - Database View or Joins in Linq to Entities实体框架 - Linq 中的数据库视图或连接到实体
【发布时间】：2011-02-28 15:10:56
【问题描述】：

我有一个包含许多查找表的数据库表：

OrderType  
ShippingType  
etc.

我的订单表引用了以下每一个表：

Order
  OrderID
  OrderTypeID
  ShippingTypeID

我使用实体框架作为我的数据访问层。我有一个需要显示订单信息的页面。我正在努力找出使用这些实体的最佳/正确方法。

我的页面应该显示如下数据：

订单 #1000000
运输类型：UPS
订单类型：在线
等类型：等。

最好在数据库中创建一个视图来带回我需要的数据，然后将其添加到我的实体模型中，然后直接使用它，这样我就不必在查询中编写连接了吗？还是像这样创建一个中间类更好：

class OrderView
{
    public int OrderNumber { get; set; }
    public string OrderType { get; set; }
    public string ShippingType { get; set; }
}

var order = from o in db.Orders
            join ot in db.OrderTypes on o.OrderTypeID equals ot.OrderTypeID
            join st in db.ShippingTypes on o.ShippingTypeID equals st.ShippingTypeID
            select new OrderView 
            { 
                OrderNumber = o.OrderNumber, 
                ShippingType = st.Description, 
                OrderType = ot.Description 
            };

这里有什么更好的方法？

【问题讨论】：

标签： c# entity-framework entity-framework-4

【解决方案1】：

您不需要join，本身。您可以将Navigation Properties 用于OrderType 和ShippingType，以便无需加入即可访问它们。你会有类似的东西：

var order = from o in db.Orders
            select new OrderView 
            { 
                OrderNumber = o.OrderNumber, 
                ShippingType = o.ShippingType.Description, 
                OrderType = o.OrderType.Description 
            };

我认为在视图中这样做没有任何好处。

【讨论】：

我一直避免在我的查询中使用 Navigation 属性，因为它们往往会产生非常奇怪的 SQL 代码和大量的多余连接。另一个问题：您是否将该查询放在“订单存储库”中......因为它不再处理订单类本身。这就是我挣扎的部分......如何将它们组合在一起。
@Dismissile：它不是在处理订单，而是关于订单的信息。因此，如果您有专门的订单存储库，请将其放在那里。另一种方法是不使用这些专门的方法，而是公开IQueryable<Order> GetQuery()，让上层定义其查询。
你能扩展第二种方法吗？我不确定我是否在关注。

【解决方案2】：

您可以使用 Linq-to-entities。当我有一些我无法在 L2E 中编写的内容（如公用表表达式和分层查询）或 L2E 性能不佳时，我通常会切换到 SQL 或 View。如果您没有这些问题，您应该对 L2E 感到满意。

顺便说一句。您的查询可以在没有连接的情况下重写 - 该死的@Craig 更快。

【讨论】：

【解决方案3】：

视图之所以好有几个原因：

它们可以使您免受基础表结构变化的影响
他们可以抽象出规范化细节（连接）
Yoi 可以撤销对表的所有权限，并通过视图提供受限访问。

尽一切可能使代码更易于理解。

【讨论】：

【解决方案4】：

使用数据库视图可能会阻碍 SQL 优化器为您提供最佳执行计划的能力。因此，如果 EF 生成的查询不可怕（使用 SQL Profiler 确保！）我会去EF。

【讨论】：