ExecuteStoreQuery需要什么来尊重关系？

Question

目前,当它失败时,我觉得有点武断.这是我的情况.

实体Foo:

 class Foo {
      int FooID {get;set;
      User Creator {get;set;}
      Bar TheBar {get;set;}
      DateTime CreatedDateTime {get;set;}
 }

实体用户:

 class User {
      int UserID {get;set;}
      ObjectWhatchamacallit Foos {get;set;}
      DateTime LastLogInDateTime {get;set;}
 }

所以

 return DB.ExecuteStoreQuery<Foo>("SELECT *, 
      Created AS CreatedDateTime,
      LastLogIn AS LastLogInDateTime
      FROM
      [User] 
      JOIN Foo ON Foo.CreatorID = [User].UserID
      JOIN Bar ON Foo.BarID = Bar.BarID",
      "Foo");

将加载Foos罚款,与酒吧,但不是造物主.

 return DB.ExecuteStoreQuery<User>("SELECT *, 
      Created AS CreatedDateTime,
      LastLogIn AS LastLogInDateTime
      FROM
      [User] 
      JOIN Foo ON Foo.CreatorID = [User].UserID",
      "User");

没有更好的表现.用户已加载,但没有Foo.

这可能是因为

1. Foo和User中的别名？
2. 用户是SQL关键字？(我已经尝试了aliasin [User] AS Creator,但无济于事)
3. 别的什么？

更新

我一次又一次地遇到这个问题.我已经意识到别名(1)可能与它没有任何关系.用户是一个T-SQL关键字(2)可能是这个特定实例中的问题,但在我遇到此问题的所有时间中并不常见.因此,一般问题的答案是它是另一回事(3).

一个问题是某些关系名称可能已经从对应于存储密钥列名称的edmx-designer最初建议的那些改变.但对我而言,这种接缝在任何情况下都是随意的.

所以我再次提出标题中陈述的一般问题,EF究竟是如何推断查询返回的列的子集实际上是相关实体的一部分？

Answer 1

事实证明我被误导了。ExecuteStoreQuery 需要什么才能尊重关系的答案？就是把自己打垮，什么都不会。

有时这对我有用的唯一原因是我在业务层中隐藏了自动加载，如果我关注 IntelliTrace，我会很容易发现这一事实。

直到昨天，我还是没有希望，我被迫接受我的模型对于 EF 来说太复杂了，我准备平衡 50000 行 T-SQL 和充满显式负载的控制器之间的界限。

对于真正繁重的查询，我开始将查询分为几个，仍然使用 ExecuteStoreQuery。所有相关结果都会自动加载到适当设置的上下文和关系中。

新发布的EF June 2011 CTF可能正是我所需要的。

我知道EFExtensions中提供了类似的功能。返回多个结果集的存储过程。截至撰写本文时，我不确定此查询需要多少次数据库访问，但我无法想象为什么需要多次访问。每个结果集最多一个，这仍然比显式加载要好得多。

让我们看看效果如何。