Entity Framework技巧系列之二 - Tip 6 - 8

Posted 2020-08-20

提示6. 如何及何时使用贪婪加载

什么时候你需要使用贪婪加载？

    通常在你的程序中你知道对查询到的实体将要进行怎样的操作。

例如，如果你查询一个订单以便为一个客户重新打印，你知道没有组成订单的项目即产品的信息重打印将是不完整的，所以你知道你将需要同时加载这些信息。

    这是贪婪加载起作用的一类场景。

如果你知道你需要额外信息，或实体，你可能也会预先加载这些实体（贪婪加载），因为这将省下生在将来的查询。

怎样进行贪婪加载？

与一些普遍存在的错误观念相反，Entity Framework中贪婪加载即可行也易行，你仅使用Include()方法如下这样启动查询即可：

1 var reprint = (from order in ctx.Orders.Include("Items.Product") 
2              where order.Customer.Name == "Fred Blogs"  
3                 && order.Status == "Unshipped" 
4              select order).First();

这个查询意思是，在每个满足查询条件的order中包含其"Items"，同时每个Item中也包含其"Product".

这样的结果是，如下代码：

1 foreach (var item in reprint.Items) 
2 { 
3     Console.WriteLine("\\t{0} {1} = ${2}", 
4         item.Quantity, 
5         item.Product.Name, 
6         item.Cost); 
7 }  
8 Console.WriteLine(reprint.TotalCost);

不再需要新的查询。

注意：

不需要显式 Include("Items") ，对 Include("Items.Product") 的调用会隐式包含Items。

 

提示7 – 怎么在.NET 3.5 SP1中模拟外键属性

背景

如果你一直关注EF Design Blog这个团队博客，你可能已经看到近期我们宣布了一个用于.NET 4.0中EF的称为FK Associations的特性。

然而在.NET 3.5 SP1中，我们仅支持独立关联。这表示外键列不会做为可用的属性出现在实体中。相反这表示你不得不通过到其它实体的引用来建立关联。

例如，不同于Linq to SQL，下面的写法在EF中不可用：

1 product.CategoryID = 2; 

因为在product实体中没有"CategoryID"这个属性。

你不得不使用类似下面的替换方法：

1 product.Category = ctx.Categories.First(c => c.ID == 2); 

也就是你需要使用Category引用。这意味着你不得不在内存中放置一个Category对象，或者像上面例子那样通过查询获取一个。

不存在一个你可以直接设置CategoryID的属性的问题可能造成很大的麻烦，而这就是我们在.NET 4.0中添加了FK Associations与FK Properties的原因。

这看起来都不错，但Julie Lerman总习惯提醒我，现在正在使用.NET 3.5 SP1的人们怎么办？我们的新特性现在帮不上忙。

所以…

怎样在CategoryID不实际存在的情况下设置它？

这问题是个圈套。你当然实现不了这种想法。

但是你可以使用下面的代码实现同样的效果：

1 product.CategoryReference.EntityKey = new EntityKey("MyContainer.Categories", "ID", 2); 

这看起来有点复杂不是吗？所以让我们拆开分析：

1. 对于每一个像Category一样的引用"xxx",Entity Framework也生成了一个返回EntityReference类型的"xxxReference"属性。（EF中大量使用EntityReference来提供完成像保持关系一致性，及基于EntityKeys的实体查找等操作所需的设施与服务）

2. EntityReference的其中一个属性是EntityKey。当我们希望改变外键的值时我们需要将一个新的EntityKey设置到EntityKey属性。

3. 要创建一个新的EntityKey，我们需要知道如下3条：

    1). 我们想要设置给"外键"的值。与前面代码段一致，这个值就是2。

    2). 目标Entity所属的EntitySet的完成限定名。在这个例子中，我们的目标是一个Category，我们由"MyContainer.Categories"集来获取Category。

    3). 目标实体中主键属性的名称。这个例子中Category的主键为"ID"属性。

很显然这不是你想要在你需要的任何地方书写的那种类型的代码。所以我们以这种方式来封装。以便…

怎样使用这些代码来仿造一个外键属性？

幸运的是Entity Framework为实体生成了部分类，所以你可以像这样简单的将这些逻辑放置于你自己的Product部分类中：

 1 public int CategoryID { 
 2     get {
 3         if (this.CategoryReference.EntityKey == null) return 0;
 4         else return (int) this.CategoryReference 
 5             .EntityKey.EntityKeyValues[0].Value; 
 6     } 
 7     set { 
 8         this.CategoryReference.EntityKey  
 9            = new EntityKey("MyContainer.Categories", "ID", value); 
10     } 
11 }

注意我们在get访问器中也使用了CategoryReference。这样我们的CategoryID属性仅就是一个基于CategoryReference的视图，这样如果EF在底层做了任何改变我们也无需被通知。

添加这样的代码后，之前我们想要的写法也就可以实现：

1 product.CategoryID = 2; 

这在做法在很多场景中都特别有用，例如MVC控制器与数据绑定中。

外传

这种解决方案本质上仅仅是隐藏了独立关联的一些限制的变通方案，同所有的变通方案其也存在缺陷。关键就是在优点与缺陷之间做出全面的权衡。一些关键的缺陷如下：

1. 部分类中的属性不会被Entity Framework所识别，所以你不能在LINQ查询中使用它们。

2. 由于在setter访问器中我们通过完全限定名引用了EntitySet，我们将Entity Class与EntitySet直接耦合在一起。对于大多数人这不成问题，但是当你试图在不同上下文间重用你的实体类型或使用MEST(MultipleEntitySets per Type)时这种方法不会工作。

3. 可能还有更多缺陷…当想到它们时我将陆续添加！

 

提示8 – 怎样使用LINQ to Entities编写"WHERE IN"形式的查询

想象你有一个人员表，你想查询其中姓氏包含于一个有趣的姓氏列表中的那部分人。在SQL中这很平常，你编写这样的查询：

1 SELECT * FROM People 
2 WHERE Firstname IN (‘Alex‘, ‘Colin‘, ‘Danny‘, ‘Diego‘) 

SQL中的IN等价于LINQ中的Contains

在LINQ(to objects)的世界不存在‘IN‘，所以你需要像倒置顺序那样来使用Contains方法：

1 var names = new string[] { "Alex", "Colin", "Danny", "Diego" };
2 var matches = from person in people 
3         where names.Contains(person.Firstname) 
4         select person;

注意语义上我们已经由SQL中的：

 value.IN(set)   

变为LINQ中的

 set.Contains(value)  

结果是相同的。

.NET 3.5 SP1与.NET 4.0对Contains的支持

在.NET 4.0的EF中将支持 IEnumerable<T>.Contains(T t) 方法，所以在下个版本EF中你可以编写上文LINQ查询那样的查询。

不幸的是这种写法不被.NET 3.5 SP1支持：当遇到这种形式的LINQ表达式时LINQ to Entities会报错，因为其不知道怎样将对Contains的调用转换为SQL。

但是我们.NET 3.5 SP1的用户怎么办呢？他们应该怎样做？

.NET 3.5 SP1的变通方案

有一个由EF团队"大脑"之一Colin提供的变通方案。

这种变通方案的本质是你可以以如下方式来重写上面的查询：

1 var matches = from person in people 
2         where person.Firstname == "Alex" || 
3               person.Firstname == "Colin" ||  
4               person.Firstname == "Danny" || 
5               person.Firstname == "Diego" 
6         select person;

当然这会使代码变长且编写这样的代码是痛苦的，但是它同样可以工作。

所以如果有一些工具方法可以很容易的创建这种类型的LINQ表达式，我们将很好的处理业务。

而恰巧不久之前Colin在论坛上给出了他完成的帮助方法，借助他的方法，你可以如下这样编写查询：

1 var matches = ctx.People.Where( 
2         BuildOrExpression<People, string>( 
3            p => p.Firstname, names 
4         ) 
5 );

这会生成一个与下面语句相同效果的查询：

1 var matches = from p in ctx.People 
2         where names.Contains(p.Firstname) 
3         select p;

但事实上后者一个明显的问题是其不可以在.NET 3.5 SP1下工作。

外传

如果你已经阅读至此，很好！

下面是使变通写法成为可能的功能函数：

 1 public static Expression<Func<TElement, bool>> BuildOrExpression<TElement, TValue>( 
 2         Expression<Func<TElement, TValue>> valueSelector,  
 3         IEnumerable<TValue> values 
 4     ) 
 5 {      
 6     if (null == valueSelector)  
 7         throw new ArgumentNullException("valueSelector");
 8     if (null == values) 
 9         throw new ArgumentNullException("values");  
10     ParameterExpression p = valueSelector.Parameters.Single();
11     if (!values.Any())    
12         return e => false; 
13     var equals = values.Select(value => 
14         (Expression)Expression.Equal( 
15              valueSelector.Body, 
16              Expression.Constant( 
17                  value, 
18                  typeof(TValue) 
19              ) 
20         ) 
21     ); 
22    var body = equals.Aggregate<Expression>( 
23             (accumulate, equal) => Expression.Or(accumulate, equal) 
24     );  
25 
26    return Expression.Lambda<Func<TElement, bool>>(body, p); 
27 }

此函数本质上构造了一个针对所有使用 valueSelector (i.e. p => p.Firstname) 的值断言表达式，并将这些断言进行OR连接来为这个完整的预言创建一个表达式，除此之外，我不打算试图解释这个函数。