如何使实体框架不联接表
本文关键字:框架 何使 实体 | 更新日期: 2023-09-27 18:33:44
好的,所以我再次测试 EF 的性能,我只想从我的数据库中返回一个简单的结果。
例
var jobsList = from j in mf.Jobs
where j.UserID == 1001 select new { Job = j };
不幸的是,这会将我的用户对象加入到此列表中,我不希望 EF 这样做。如何告诉 EF 不要仅仅因为存在关系而加入。基本上,我只想从该表中获取一个简单的行。
还是我需要使用不同类型的检索。我仍在使用下面的基本数据库检索类型,我觉得现在有更好的方法来处理数据库工作。
SqlConnection myconnection = new SqlConnection();
编辑
基本上,我在更清晰的上下文中所说的内容。是不是只得到以下内容。
Job.JobID
Job.UserID
//Extra properties
我得到
Job.JobID
Job.UserID
Job.User
//Extra properties
该 User 对象很容易消耗比所需更多的内存,而且我不需要它。
我的解决方案
所以我仍然不太相信 EF,这就是原因。我关闭了LazyLoad并打开了它,并没有真正注意到那里有太多的性能差异。然后,我将 SqlConnection 类型方法使用的数据量与 EF 方法进行了比较。
我得到了完全相同的结果集,这是性能差异。
对于我的实体框架方法,我返回了一个作业列表。
MyDataEntities mf = new MyDataEntities(); // 4MB for the connection...really?
mf.ContextOptions.LazyLoadingEnabled = false;
// 9MB for the list below
var test = from j in mf.Jobs
where j.UserID == 1031
select j;
foreach (Job job in test) {
Console.WriteLine(job.JobID);
}
对于我的 SqlConnection 方法,它执行存储过程并返回结果集。
//356 KB for the connection and the EXACT same list.
List<MyCustomDataSource.Jobs> myJobs = MyCustomDataSource.Jobs.GetJobs(1031);
我完全理解实体框架比标准 SqlConnection 做得更多,但如果结果集至少需要 25 倍的内存,为什么还要大肆宣传。只是似乎不值得。
我的解决方案毕竟不是使用 EF。
User
属性是作业类的一部分,但在您访问它之前不会加载(延迟加载(。所以它实际上不是"加入"。
如果您只需要两个指定的列,则可以写入
var jobsList = from j in mf.Jobs
where j.UserID == 1001
select new {
Job.JobID,
Job.UserID
};
此行为的最可能原因是您已将LazyLoadingEnabled
属性设置为 true。
如果是这种情况,则不会在原始查询中恢复用户。但是,如果您尝试访问此属性,即使您在调试时通过检查执行此操作,也会从数据库加载此属性。但前提是您尝试访问它。
您可以打开 SQL Server 事件探查器进行检查,并查看开始向数据库发送哪些命令。
您的代码未使用预先加载或显式加载。所以这一定是原因。
我认为EF不知道你只需要一个结果。尝试这样的事情。
Job jobsItem = mf.Jobs.Single(j=>j.UserID==1001)
如果你不想使用兰巴斯...
Job JobItem = (from j in mf.Jobs where j.UserID == 1001 select j).Single()
我现在附近没有编译器,我希望语法是正确的。如果您喜欢,可以使用 var
而不是 Job
来表示变量。它没有效果,但我认为在这种情况下Job
更具可读性。
在访问作业的用户属性之前,用户实际上不会附加到上下文。如果要获取 User 的 null,请关闭延迟加载。
实体框架不支持属性的延迟加载。但是,它具有表拆分功能
强调了属性。当然,实体框架支持延迟加载行