使用和不使用ObjectResult的LINQ to Entities之间的区别(Difference between LINQ to Entities with and without Object

使用和不使用ObjectResult的LINQ to Entities之间的区别(Difference between LINQ to Entities with and without ObjectResult)

我有以下LINQ to Entities查询...

var results = from c in context.Contacts select c;

它可以很好地返回一组联系人。 但我见过这样做的示例代码......

ObjectResult<Contact> results = (from c in context.Contacts select c).Execute();

有什么不同？ ObjectResult还有一组返回的联系人。 它只是语法还是存在真正的根本区别？

I have the following LINQ to Entities query...

var results = from c in context.Contacts select c;

which works fine in returning a collection of contacts. But I have seen sample code that does this instead...

ObjectResult<Contact> results = (from c in context.Contacts select c).Execute();

What is the difference? The ObjectResult also has a collection of returned contacts. Is it just syntactic or is there a real fundamental difference?

最满意答案

ObjectResult <>只是在您开始枚举IQueryable <>（即context.Contacts）时由EF返回的类型。

因此，如果您立即枚举两个查询中的任何一个，从语义上来说它是相同的。

唯一的区别是，在第一个示例中，如果编写更多查询操作，它们将被附加到枚举时发送到数据库的查询，而在第二个示例中，它们将通过LINQ to Objects在内存中应用。

此外，Execute（..）提供了一些更容易访问MergeOptions的功能（例如，如果数据库副本覆盖已经在内存中的副本，反之亦然）。 您也可以使用ObjectQuery <>上的MergeOptions属性执行此操作，但这有点麻烦。

希望这可以帮助

亚历克斯

ObjectResult<> is simply the type returned by EF when you start enumerating the IQueryable<> (i.e. context.Contacts).

So if you immediately enumerate either of your two queries, semantically it is the same.

The only difference is that in the first example if compose more query operations they will get appended to the query sent to the database when you enumerate, whereas in the second example they will get applied in memory by LINQ to Objects.

Also Execute(..) provides somewhat easier access to MergeOptions (like, should the database copy overwrite copies already in memory or visa versa). You can do this using the MergeOptions property on the ObjectQuery<> too, but that is a little more cumbersome.

Hope this helps

Alex